Pair programming? What about pair engineering?

I don't know of anyone who actually does Pair Programming as a standard practice. I know a few places tried it a while back, but even most of the groups that have otherwise embraced "Extreme Programming" practices don't do Pair Programming.

I think it might work under certain circumstances, but you'd have to have two people who really work well together over the long haul, and that isn't easy to find.

My company does pair programming. Not 100% of the time, but most of the time.

There are a lot of conversations generated in this type of environment.
Assumptions and design ideas are constantly being challenged, which lead to better products.

In addition, We increase the knowledge coverage of the system. It allows us to get away from "well, that's Fred's code. Only he knows that code and only he can change it."

We also try to rotate our pairs, so its not always the same two people pairing. Again, this increases the knowledge coverage, and also allows the team to learn from each other a lot more.

As far as decreasing bugs, I do believe pair programming has helped. But that's just one aspect that has helped. We also use TDD (test-driven development) to validate that the design, and we do a lot of automated testing (unit, integration, and end-user testing). We use continuous integration to run our entire test suite whenever code is checked in. This gives us the confidence to change our system without fear of breaking other parts.
So I believe its the combination of these practices that has helped us not only decrease our defects, but its also set up our system to be easily changed and maintained.

I think this would also work in other engineering disciplines, although I don't have any direct experience to speak of.

Hope this helps.

-Gary

Gary,

Thanks for the detailed explanation.

I had not considered the obvious benefit of having twice the people who intimately know the particular code. In our hardware design environment, more often than not a huge gap left when someone leaves, with much scrambling to take over a responsibility before the knowledge is lost.

The obvious cost-benefit downside is counting two designers as one; i.e., staffing twice as many designers on the project. So this is where I'm surprised that management teams have realized the benefits of such an endeavor, and continued implementing it despite the up-front costs. That's a kudos to your management. The software verification effort you described sounds quite similar to our hardware verification strategy.

I do think such an initiative might work in hardware logic design, and except for the common inter-personal snags that can pop, I can see this approach leading to less bugs finding their way into the chip (for the verification engineers to eventually uncover.) I can't think of a reason it wouldn't work; after all, at the end of the day we're all coding.

Matt
--

Matt,

I agree that is a very good idea, but I think it is difficult to be adopted in the semiconductor industry, at least not in the U.S. where the engineering cost has been a big target for reduction.
The very top management will not understand doubling the technical team without equal (or greater!) increase in productivity. The quality will increase, for sure, but it is not a good justification for them.
Maybe it can be adopted in a small company that prizes quality over quantity...

Also, think about the logic team you know. There are always some people that would be very hard to work with. If you implementing this idea with new grads, it will be perfect! For old dogs, I see potential problem for some...

Lincoln.

Yes, that's true. There are some folks who, while "working" in pairs, would do nothing but argue non-stop about the way a block should be implemented. But then again, if nothing is designed, technically that does lead to less bugs!

Matt
--

I work with Indian programmers a lot and do quite a bit of outsourcing. We use http://gotomeeting.com on a daily basis and frequently share ssh sessions . . . does anyone know a linux command line tool to allow two persons to work simultaneously in the same ssh session, sharing the same editor? Right now, like I say, I do this with gtm but am looking for a command line alternative.

Probably the easiest way to do this with be via a vnc session where you both worked on the same ssh session terminal window.

Yes, I'd agree. VNC through an ssh shell or tunnel is a good way to go.