As the proverb says, “Data speaks louder than words.” Well, if it’s not a proverb then it should be.
The only way to know for sure if pair programming is right for your team is to track progress and see if the metrics that are important to you improve as your team starts to become more collaborative with pairing.
What are the metrics that are most important to you? When I look at pair programming, the most important indicator that I focus on is code quality. When I say code quality I mean several things.
The easy and quick way to interpret what I mean by code quality is to look at the testability of code. If developers are producing good, testable code that has automated unit tests and can independently verify each feature then I know I have a true measure of my progress and I have a good sense that high-quality code that’s straightforward to maintain and extend is being produced.
For me, the number one metric that I look at is testability in code but there are other metrics that you can look at such as code coverage and cyclomatic complexity, as well as many other indicators.
I also want to look at the amount of work that the team is doing but generally, I don’t like to track story points. Rather than assign tasks with different story points, I like to help teams get good at breaking tasks down into their smallest components so that every task is a small task and then instead of counting story points we simply count tasks.
The number of tasks the team can complete within an iteration is likely to be similar to the number of tasks the team completed in the last iteration or the one before that. Generally, if the team isn’t trying to do something very different than they were doing before then one could expect that the team’s throughput would be similar to their past performance.
How much more precise do we need to be and how much are we willing to pay for that precision? Historically, we’ve been very bad at estimating how much work needs to be done, especially as the time horizon increases. Estimation can help with planning but an estimate is not a deliverable. I find that often managers are willing to pay far more than they should for an inaccurate estimate that didn’t make any difference on the project.
I think that planning and estimation, especially the way it is practiced in Scrum, is largely a waste of time and can be inappropriately used by management as a way of forcing developers to get more done even at the expense of cutting corners and incurring technical debt.
Many of the ways that we track progress in software development actually de-incentivizes developers from doing the right things. If we are incentivized to make local optimizations but those local optimizations don’t affect the overall throughput, then the ultimate value of those optimizations is still very low.
If your team spends a lot of time in triage fixing bugs then finding ways to prevent bugs from being created in the first place could hold a great deal of value. Traditionally, this is one of the benefits of pair programming.
I find that for many tasks pair programming can be more efficient and effective but you can’t assume that two people will immediately get the work done together that they could have done by themselves in the short term because there is always a learning curve. It can take some time before two people get into enough of a groove to really get high productivity. But when it happens it can be magic.
I like to look at before and after data, a lot and generally I look at things like defect rates before and after a practice is introduced. I also look at code coverage and cyclomatic complexity but just as indicators on code quality because I don’t think we can programmatically determine whether a piece of code is good or not, we have to examine it ourselves.
Ultimately in my experience, I find exactly what the published studies find, which is that pair programming improves not only developer quality but also productivity. Fewer defects are being created, more requirements are being interpreted in ways that are of value to the customer and technical skills are being propagated throughout the team so that everyone’s collaborating more effectively and efficiently.
When I see teams who adopt Extreme Programming practices such as pair programming and the gains that they make over their competition I see how much of a competitive advantage high performing teams can be, especially in highly competitive and high-stakes markets.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Agile Infrastructure.
Previous Post: « Let Teams Decide on the Details
Next Post: Why Practice 5: Create CLEAN Code »