Agile Zone is brought to you in partnership with:

Chris Spagnuolo has been working in the Geographic Information Systems (GIS) field for nearly 15 years. If it involves GIS, he's probably done it...everything from field data collection to large scale enterprise GIS deployments. Through this experience, he has reached the conclusion that the most effective way to deliver value is by the implementation of agile practices. He believes strongly in the effectiveness of agile practices and he is leading a new group to evangelize the benefits of agile. Chris is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. You can read more from them at their website. View Full User Profile

Pairing for Quality

12.28.2012
| 2110 views |
  • submit to reddit
OK, so if you didn't guess it, quality software has been on mind a lot over the past two weeks. And why shouldn't it be? It should be foremost in all of our minds (if you're in software development). It's what our customers expect and demand. They don't want buggy, defect ridden software. Unfortunately, things like software quality and testing are usually seen in a budgetary/cost light instead of the customer satisfaction light. I've beaten this point to death already and by now you already know that in my opinion customer satisfaction is paramount. And, anything we could do to improve the quality of our products should be pursued vigorously.

We've discussed the CIO commitment to quality already, and we've looked at ways to tightly couple QA/testing into our iterations. Today, I started thinking about other places in our development cycle where we could really show great strides in improving software quality. I think I found one: Lets take a look at pair programming. The first thing most people say when I mention pair programming is "Why would we do that? We'll have two developers doing the same work that one developer can in the same amount of time!". OK...fallacy number one: This simply isn't true. Studies have shown that pair programming doesn't reduce productivity by 50% as implied by the previous statement. In fact, pair programming reduces productivity by only about 15%. WHAT!!!! Yes, I admitted that pair programming reduces productivity. But, the 15% loss in productivity is made up for by gains in reducing defects.

Two pairs of eyes on the same code as it's being written has been shown to dramatically reduce the number of defects in the code. So much so, that if you factored in the gains recovered by NOT having to fix defects later in a development project, or worse yet, in production, the productivity of pair programming is 100% of what it would be if the two developers worked independently. That's right, we more than make up for the 15% of productivity lost by pair programming by not having to fix defects later on in our development (or worse yet in production). Plus, cutsomers (remember them?) get the added bonus of low-defect or defect-free QUALITY software. Based on these facts, the productivity/cost argument for not doing pair programming is essentially invalid. So, the next time you hear the productivity/cost argument against pair programming, resist the urge to agree with it. Pair programming works. Try it, you'll be amazed at the results.
Published at DZone with permission of Chris Spagnuolo, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)