A Fork in the Road
I got into an interesting conversation the other day with my pairing partner about the approach he and I wanted to take while trying to fix a bug. What followed was something of an existential conversation about software, complexity, and the role of the programmer in managing complexity.
We work with a small but quite tangled system. The system itself is only a few years old but contains many technologies and bears the scars of several smart but inexperienced people learning how to design as they went. I won’t articulate the details of the bug we were experiencing but I will say that it is something that recently appeared and was troublesome but non-critical.
The difference in our two points of view became apparently very quickly. My desired approach was to try to pin down the bug, deconstruct it to the point of understanding, and then apply a fix. My coworker’s approach was to make a well-educated guess about the cause of the bug and apply a refactoring to our codebase that would address the anticipated problem.
His reasoning was that our codebase was too complex to spend time trying to understand it in detail, and in the worst-case scenario we would still have completed a useful refactoring that improved the quality of our codebase. I found this a bit hopeless. Is software really so complex that we as programmers now have to act like doctors – diagnosticians – making reasoned guesses about the world around us? Is there no more engineering?
10 or 15 years ago I would have considered his approach ridiculous. Now I’m honestly not sure. Modern software systems contain so much abstraction and layering that it is really hard to judge the level of effort that will be involved in addressing any one problem.
So what option did we choose? We guessed and did the refactoring. I don’t think I would have agreed to that with just any pair partner, but this particular coworker is a very productive programmer. He had a clear path forward and a clear rationale. And one thing you don’t do with a productive programmer is get in their way.
Did it work? No. I almost want to say “OF COURSE NOT!” but that would be unfair. It could very easily have worked. What did eventually work? A pair sitting down and tracing through the application stack with gdb. And even that has only located the approximate location of the error. We still haven’t solved the problem yet. But we’re much closer.