One of the most compelling arguments against pair programming is the perceived additional cost. From an accounting perspective, we are paying two salaries to produce the same amount of code. There are perceptions this thought is based on which I would like to question.
- Do two people working together produce only the same amount of code as one person, or will they produce something between what one person and two people can produce, or maybe more that the two produce independently?
- Do both individuals in a pair have the same skill set or knowledge of the code based being modified?
- What about security?
- Is the quality of the software higher when written by two individuals of greater quality, measured as less bugs?
I can’t readily measure the first question. My perception is that two individuals may produce more quality code together than working indpendently. I don’t have any proof to offer on that thought. So, we’ll leave it at that. It’s something you may have to try and see for yourself.
Regarding the second question, pair programming is a great way to do knowledge transfer. You can use it to mentor others into the design and architecture of your code. You can teach people new techniques without takeing time away from producing something of value directly for the company. You get training and working code for a single effort, and the code they have learned is not something contrived for a learning exercise.
Have you ever seen back doors into code written by developers? Certain certifications REQUIRE code reviews. We used Pair Programming instead of Code Reviews when I was working under PCI certified software. It’s much harder to get two people to agree to create hacks. Moreover, writing secure code isn’t fun. You’re more likely to get two people to follow secure practices than an individual.
Finally, lets consider the escalating cost of errors in software. For that there is a lot of scientific study providing us with compelling evidence that two persons produce higher quality, and that higher quality is a cost savings. Here is a quote taken from a NASA study on the cost of bugs through the software lifecycle, found at http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf.
“The results show the degree to which costs escalate, as errors are discovered and fixed at later and later phases in the project life cycle. If the cost of fixing a requirements error discovered during the requirements phase is defined to be 1 unit, the cost to fix that error if found during the design phase increases to 3 — 8 units; at the manufacturing/build phase, the cost to fix the error is 7 — 16 units; at the integration and test phase, the cost to fix the error becomes 21 — 78 units; and at the operations phase, the cost to fix the requirements error ranged from 29 units to more than 1500 units.”
While NASA is directly addressing requirements errors, similar costs may be accrued by incorrect implementation of requirements, or developer instigated bugs. Notice how cost escalates in a factorial fashion. So, a bug found in development, taking the lower end of the units, would have a ratio of 3 to 21 if found during testing. That means a bug costs 7x as much to fix if found during testing than if found during development. Depending on the number of bugs introduced, at a 7x hourly cost, it doesn’t take long to catch up the 2x cost of pair development.
Just ask yourself, how many times have you found a bug in production code? It takes only a minute to fix, but multiple man hours to deploy. As a result of the cost to deploy the fix, it is either delayed to bundle multiple changes in order to reduce the cost of deploying, causing the business to wait for your next window. Or, you do a single patch for the bug, wasting precious time getting a fix out, that may likely have been found during initial development with two sets of eyes.
To be clear, not all code benefits from Pair Programming. Code that is boiler plate is a good example where you should work alone. The program won’t compile, or the application won’t work, if boiler plate code has bugs. When doing SQL I have not found a lot of work benefiting from Pair Programming. Most SQL Code is simple Create, Retrieve, Update, Delete (CRUD) methods. Sometimes there are places where stored procedures are the best place to manage multiple tables concurrently. They can get tricky, and set logic can twist your brain around.
So, the math is not as straight forward as the bean counters would like it to be. My personal experience has been that two people working on the same problem produce more bug free code together, than those same two people working independently. Even if you only break even, think of the value you provide by having less bugs in your code. What is that worth? It’s not that hard to turn the perception of quality into money. Whereas a lack of quality can put you out of business.
Cheers,
Ben