Agile Software Development Depends on Pair Programming

One of the core practices of agile development is pair programming. That means two programmers work together on the same body of code. As they work they are constantly discussing the design of the programs and the algorithms used, and they are constantly checking each other’s work to see that it meets coding standards and to see that thorough unit and function testing is done on the code they produce.

Question: Is pair programming really just paying twice for the same code? In a time like now when we are all under pressure to reduce cost by outsourcing programming work to low cost providers why are people in the agile development world talking about something like pair programming? Is the quality of the code produced by pair programming really worth the extra cost?

[ I do lively presentations on this and related topics - mhugos@yahoo.com ]

The Agile 2009 conference is happening this week in Chicago and I’m attending the conference to find out about the current state of agile development and get answers to questions like why is pair programming considered so essential to agile development. This afternoon I talked with Josh Kerievsky who uses pair programming on development projects in his company and who swears by it. His company is also in the business of coaching and training their customers in how to do effective agile development using pair programming and the other core agile practices. Josh’s company is Industrial Logic.

“As a business owner I can’t afford to have people working solo,” said Josh. “Pair programming is about removing bugs in the code and reducing the risk of bad program design. I don’t insist on pair programming because it is the agile thing to do, I insist on it because it delivers the best value for the money I spend.”

Myth of the Hero Programmer Revisited

I asked him what he thinks about the legend of the hero programmer working on his own, tapping away on his keyboard into the wee hours of the night and producing thousands of lines of code that makes computers do amazing and wondrous things. He began his response by observing that what the so-called hero programmer actually produces is thousands of lines of code that nobody else understands and nobody can maintain or enhance.

Josh went on to say that the solo programmer usually also violates other agile practices such as adhering to coding standards, doing good unit and function testing, and creating simple program designs. Often the reason for this is that solo programmers cannot take criticism from other developers because their code becomes so personal and any criticism of it feels like a personal attack. But when developers do pair programming, they are much more open to review and criticism of their code because they think of their code as a joint production and therefore they don’t feel personally attacked when their peers review and criticize their work.

I asked him about the best ways for programmers to pair up. I wondered if he ever saw differences between pairs that were man-man or man-woman or woman-woman. He said he leaves it to his developers to pair up and select who they want to work with. He said he doesn’t see any difference between pairs that are man-man or man-woman or woman-woman. His developers know each other and they know who they work well with. His only requirement is that he doesn’t want two programmers working together if they are both inexperienced in the technology being used; at least one of the pair needs to be knowledgeable

Continue Reading