Pair Programming: Where Teamwork Comes Out
September 30th, 2009 @ 1:00 am
The New York Times did a profile on the topic of pair programming, the art of writing software with a partner. They looked at it through the eyes of an individual who does pair programming every day.
The profile is pretty good, and makes a strong case for pair programming. While I’m not fully prepared to surrender my freedom to another person for 100% full-time pair programming, I think that doing pair programming is something that can be very effective.
One thing that the New York Times doesn’t really play up is that pair programming is good for management. This is sometimes lost on management, who wonders why they should use two programmers to do the work of one. They miss the point, though, when they do the math. First, a second programmer provides a second set of eyes, meaning that bugs are reduced. Fixing bugs takes time, and this reduction in bugs actually saves time. Second, management also misses the fact that two people put in eight hours of productivity each day, together, rather than perhaps four hours total, if they were programming separately. This is due to the fact that programmers get bored, get distracted, or generally get off task, but with another person there is a peer pressure to keep working.
At the end of the day, even if the lines of code written are lower, the problems solved, bugs avoided, and logic worked out is of higher quality and improved stability. For those who have never tried pair programming, I highly recommend it.
The original work of Brandon Savage.
No related posts.
Categories: Business Management
Ernie Leseberg wrote at 10/4/2009 12:23 am:I agree with the comment of Artur. In my experiences of pair programming works well in the early stages of development, when beginning to implement an overall design. It helps programmers confirm they are moving in the same direction with a higher quality foundation.
Brandon Savage (@brandonsavage) wrote at 10/4/2009 7:10 am:Another way that I use it is to teach a new developer on a project the ropes. They understand logic, but they might not know the ins and outs of a particular application.
Web developer, amateur photographer, lover of the outdoors and travel. Expect to find me writing code, hiking or visiting new places. I own Blueprint DC and live in Washington, DC. Follow Me On Twitter!- July Slides
- Some Thoughts On Software Licensing
- Interfaces Make Testing Easier
- Revisiting: Why Every Developer Should Write Their Own Framework
- The Fallacy of Sunk Cost
- PHP: The Good Parts – Book Review
- 1st Amendment, Meet 4th Amendment: The Gizmodo Search Warrant
- A Closer Look At ArrayObject
- TEK Webcast Notes
- Caching For WordPress – A TEK-X Webinar
I only use it from time to time on mission critical stuff but its not a bad way to work.
Also important fact is that you get better design and less hacks and less shoddy temporary solutions. People working together have deep inner force to ‘prove’ themselves so they wont go for shoddy solution as they would locked alone in he basement.
And finally you get more knowledge spread around the team.