Pairing for Quality

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.