Archive for the ‘practices’ Category
In the post, Michael tells about a design he made, which he then handed over to a colleague for implementation, followed by regular reviews. The design (or a modification of it) had a problem that neither Michael nor his colleague did spot – until a bug was reported that was caused by the problem.
Michael’s argument for why he didn’t see the problem earlier hits spot on:
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.
I, too, have made the experience that you need to be working on the code, writing the tests, calling the APIs in order to get that feeling that something really should be improved. That way, you get the feeling before it really hurts. Regular reviews can help, but can not replace that hands-on experience.
However, Michael comes to the conclusion that this example is not enough to justify having a pair programming factor of 100%:
[…] writing that part of the library took weeks. Fixing the design problem in an intense refactoring session took two days.
That point aroused my interest. Two days vs. two weeks. Of course, you’d rather spend two days for bug fixing than having both developers tied together for two weeks, right? Well, let’s see.
First, I’m asking myself, how much time was spent for reviews, communication, and support during those two weeks? In general, in scenarios where a lead developer creates a design implemented by another developer, what is the inherent pair factor, i.e. the percentage of time the two developers need to spend together anyway?
Of course, this depends on the level of skill as well as the coding and domain experience the implementing colleague has. As a matter of fact, I know that Michael’s colleague is a skilled person, but still, in my own experience, when one developer makes the design and another implements it, a lot of communication and a lot of thorough reviews are needed. And that takes a lot of time.
With that inherent pair factor defined, the next thing I’m asking is: if the two developers had worked on the feature together, would it really have taken two weeks to complete? In my experience, features tend to get solved much more quickly by pairs than by single developers. This is probably due to different factors, but for me personally, pair programming tends to raise my load factor because my peer forces me to avoid distractions more rigorously, and it improves my feature throughput because when I am forced to give in to a distraction, my peer can continue working on the feature. That both fills the time I’m distracted and avoids the time costs of the mental context switches involved with the distractions.
Then, there is another well-known principle to consider: the longer a design problem exists in the code, the more expensive it will be to fix. There will inevitably be workarounds built around the problems, other code will come into existence making use of the problematic design, tests will be written based on the design, and so on. All of these make the problem harder to fix the older it is. In Michael’s specific case, a bug report informed the developers of the problem. I assume that bug report came from QA, which of course is much better than a bug report by a customer (which may cost you in terms of time, money, and reputation), but even so: the time spent by QA people for spotting, reproducing, documenting, and communicating the bug is significant and should not be ignored.
So, what’s my take on this? Let’s do 100% pair programming for everything?
Ideally, yes. Realistically, that’ won’t be possible. But let’s at least try to be fair when calculating the costs of not performing pair programming. In the face of the inherent pair factor, the lower feature throughput, and the growing costs of design and code problems over time, I think that a reasonable amount of pair programming is sensible. Even economically.