I just read Larry O'Brien's article about there being no silver programmers. He makes the case that although there may be great variance in programmer productivity, "the significant thing is not that some professional programmers are awesome, it's that some professional programmers suck". I admire Larry O'Brien greatly, and I think there is much wisdom in what he says here.
But I think he's missing something.
I have noticed a trend in my own productivity: my productivity varies greatly with the code base I'm working on. This variance may be greater than that between individual programmers. While many are rightly concerned with individual and team productivity, no ever talks about code base productivity. If we do, where does it lead us?
A few years ago, I was working for a small medical software company. One project was a new venture with a new code base. Though new, the code was already difficult to work with. Its design forced the developer to duplicate work. In my first meeting about the project, I was told we had to do lots of "fat fingering". I didn't even know what that meant. It turned out to mean typing almost the exact same thing over and over. I was horrified and ultimately wrote a code generation tool to automate the work. Though creating and maintaining it was extra work in itself, without it, doing many common tasks in this code easily took 3x longer than necessary.
After that project was "shelved", I was moved to the company's main product, which was older and had a much more "mature" code base. Actually, half was new-style (similar to what I had been working on) and half was old-style. The old-style code was even worse to work with. It was so bad that I was almost giddy whenever I could work on the new-style code. I'm sure you know what kind of code I'm talking about. Doing anything in this code easily took 3x even longer.
Combined, that's 9x slower. That seems too high. Is it even possible? How can a code base reduce productivity so much? Here are a few possibilities I thought of; I'm sure you can think of more:
- Bad code leads to more code, and more code is slower to work with
- Bad code is hard to understand
- Bad code is dangerous to change
- Bad code leads duplication of effort
- Bad code leads to a slow change-compile-test cycle, leading to wasted time and loss of focus
- Bad code from third party libraries can drive you crazy by crashing, malfunctioning randomly, or having little documentation
- Bad code saps energy, interest, and morale
A bad code base makes any programmer less productive. Have you ever noticed that when you work from scratch with no code base to weigh you down, you can be much more productive? Imagine that as your baseline productivity. Now think of how long it takes you to accomplish something similar on a project that you're working on right now. How does it compare? I bet you're slower on the existing project.
But wait just a minute. Imagine if my list of the effects of bad code were reversed. What if, instead, it read:
- Good code leads to less code, and less code is easier to work with
- Good code is easy to understand
- Good code is safe to change
- Good code avoids duplication of effort
- Good code leads to a quick change-compile-test cycle
- Good code uses libraries which remove the need for "dirty work" and let you focus on the important problems
- Good code is fun to work with!
A good code base makes any programmer more productive. Have you ever worked on a project that was so wonderful that you could crank out magnificent results almost effortlessly? Perhaps it has a great DSL embedded in it or has powerful infrastructure.
Even with conservative estimates, if bad code slows us down 5x and good code speeds us up just 2x faster, that's easily a 10x difference.
Maybe silver programmers don't exist. But is there "silver code"? What if there are programmers who are more adept at writing silver code? If they can make a code base that's just 2x easier to work with long-term, then that makes everyone that works on that code 2x more productive, possibly forever. If such programmers exist, then they must be extremely valuable, not so much because of their own productivity, but because of the effect they will have on the productivity of others in the future. Perhaps rather than "silver bullet" programmers that kill werewolves, these are just "garlic programmers" that ward of vampires.
Given that productivity can vary so much with quality of existing code, perhaps its worth looking for "garlic programmers" who will write code that will keep the rest us of productive long-term. I leave it as an exercise for the reader to figure out how to measure a programmer's garlic-ness :).