Tue, Aug 25, 2009 0:56 EDT

Agile Software Development Depends on Pair Programming

The result of developers working solo is an accumulation of technical debt

Posted by: Michael Hugos in Best Practices

Topic: Development

Current Rating: Comments: 5

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?

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 in the technology. Other than that, the only time he sees problems within a programming

You do not have flash or javascript support.

Average (1 vote)

All Comments Comments

Tue, Aug 25, 2009 7:54 EDT

Refractor

Posted by: Ripple
Rating:

This chapter takes you through the process of refactoring a function that generates prime numbers, which I personally didn't care for too much. Maybe when I read it over again at some point I will think differently.Thank you..
Ripple @ remedies for tinnitus

You do not have flash or javascript support.

Reply to this comment | Post new comment | Report as spam

Tue, Aug 25, 2009 19:52 EDT

Pairing up

Posted by: jlipton
Rating:

We embrace agile concepts and processes but have never been able to fully adopt the paired programming component.
I know we're not alone and it's generally acknowledged that this is one of the hardest parts of the methodology to accept.
Some of our reasoning goes like this:

Paired programming can make some programmers lazy and it's highly dependent on the styles and personalities of the two people. I'm a morning person, Kevin sometimes works from home...
Open source development can be viewed as paired programming taken to the next level. If many developers become responsible for a codebase you should be able to do even better than using pairs.
The size of the development team matters. Unit tests are the key to agile development success. We prefer to have one developer writing test cases and harnesses with another coding.

Justin Lipton

Exari Systems
Boston | London | Melbourne | Munich
Test drive our software online - demo
Read our document assembly blog - blog.exari.com

You do not have flash or javascript support.

Reply to this comment | Post new comment | Report as spam

Wed, Aug 26, 2009 8:15 EDT

Pairing is *not* a "core" Agile practice

Posted by: Alan S Koch
Rating:

While I agree that most Agile teams could benefit from pair programming, it is clearly *not* a core concept.

1) Check out the Agile Manifesto & 12 principles -- pairing is not there.

2) Talk to successful Agile teams. The majority do not pair at all, and those who do don't do it 100% of the time.

Pairing is a core concept of Extreme Programming (XP), *one* of many Agile approaches. And it has great benefits. So I recommend that everyone try to include pairing in their Agile practices.

But if you can't make the case, or if your not being successful with pairing, don't fret! it doesn't make you not-Agile!

You do not have flash or javascript support.

Reply to this comment | Post new comment | Report as spam

Wed, Aug 26, 2009 10:14 EDT

"6 core practices"?

Posted by: Rob Bowley
Rating:

Firstly great article I'm a real PP advocate too and the more people justyfying it the better.

However:

(Note: the six core practices for agile software development are: pair programming; coding standards; unit and function testing; refactoring; simple design; and the 40-hour week)

Who says? There are no core practices for agile software development. There are only principles.

You do not have flash or javascript support.

Reply to this comment | Post new comment | Report as spam

Wed, Sep 2, 2009 12:44 EDT

A word in favour of pair programming

Posted by: EugeneNizker
Rating:

“Pair programming is a core agile practice”; “Pair programming is not a core agile practice” – who cares, really?! The important thing is, does it make sense or not?

My teams practice it for years, and we do see a difference. We don’t pair program to the extent some other teams do (at Menlo Innovations, for example, 100 percent of tasks are pair programmed). For example, we didn’t insist on pair programming when a task is simple and straightforward or other way around when one needs a quiet time to think something through (although this case is arguable). However, majority of tasks were done in paired mode, and again, the difference was huge.

One more comment. I am sorry, Justin, but to say that “Paired programming can make some programmers lazy” is to call black white. Nothing can be further from reality. Try to pair program and you will see how draining this experience is, how much more discipline it requires and how your brains are working at full speed. I doubt you’ll be able to walk straight after 8 hours! But! You will notice that the quality of code is completely different and, exactly as Josh Kerievsky suggests, the company saves on testing and code maintenance.

Unfortunately, your other two suggestions are equally not very valid.

Truly,
Eugene Nizker
Evident Point Software.

You do not have flash or javascript support.

Reply to this comment | Post new comment | Report as spam

Post new comment

* Subject:

* Username:

* E-mail:

The content of this field is kept private and will not be shown publicly.

Homepage:

* Body:

Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <blockquote> <strike> <p> <br>
Lines and paragraphs break automatically.

More information about formatting options

Are you a person?: *