Spotting Design Flaws

February 28, 2010

Today, I want to tell you about a startling revelation regarding the effects of pair-programming on your code’s quality. I mean, sure, there’s tons of literature out there raving about pair-programming and its benefits on code quality, but when it comes right down to it, you always have to explain why it’s cheaper to have two programmers working on a problem instead of just one.

Okay, sure, there’re the obvious reasons, such as breaking in the new guy, establishing collective code-ownership, creating a highly complex piece of software or security critical feature. But how do you argue for the benefit of pair-programming when you’re writing more or less run-of-the-mill code that’s just supposed to be rather bug-free and reasonably well refactored, and you have a team of great programmers already attuned to the problem domain?

Well, there’s at least one scenario, and that’s spotting design flaws and more importantly, finding a solution to them. See, here I was, happily sketch a design and handing it off to a colleague for implementation, then doing regular reviews. Eventually, there was a point where an alteration was necessary. At the time, the proposed solution seemed reasonable. I probably wasn’t perfectly happy about it, but it appeared to be well refactored and following the principal of separation of concerns, so I just went with the flow because it got the problem solved.

Obviously, it wasn’t the right solution, or I wouldn’t be blogging about it now. The big surprise was the way I realized not just the problems in it—aside from a bug-report—but also the solution: I was refactoring to fix the bug.

You see, that’s the big difference between doing a review and sitting right there next to your partner in crime. In one scenario, you’re a passive observer, highlighting obvious troublesome spots and talking about established facts. In the other, you’re actively involved in massaging the code, feeling the awkwardness, and hopefully sparking that part of your brain that’s responsible for solving the big mysterious of our time.

Unfortunately, all things considered, this example perfectly establishes why being actively involved in the process leads to better results, but it still doesn’t make a good case for twisting the review-knob all the way to 100%.

Why, you ask? Well, writing that part of the library took weeks. Fixing the design problem in an intense refactoring session took two days.

So, bottom line: Two guys working on two parts of the system can still be more profitable than two guys sitting right next to each other and sharing a keyboard. But you have to be aware that the design will suffer from it. But if you have a great team, the odds that you will come out ahead of the game are still better than even.

On a parting note: Right now I’m musing whether or not turning review sessions into refactoring sessions might be a way to mitigate this problem a little bit more…


One Response to “Spotting Design Flaws”

  1. That post made me think: What are the costs of _not_ performing pair programming? Started as a comment, became a blog post:…/…not-pair-programming.aspx 🙂

Leave a Reply