In reaction to No Silver Programmers, several people have spoken to the compounding benefits of good programmers (or the compounding pain of bad programmers). This is an excellent point. I think it's best put in \<a href="http://www.valuedlessons.com/2008/01/garlic-programmers-for-silver-code.html"" target="_blank" rel="noopener noreferrer">this blog post, which takes the focus away from the developers and speaks of the quality of the codebase and the ease with which changes can be made.
[N]o one ever talks about code base productivity. If we do, where does it lead us?...[D]oing many common tasks in this code easily took 3x longer than necessary....[S]o 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....A good code base makes any programmer more productive....
Maybe silver programmers don't exist. But is there "silver code"?
[\<a href="http://www.valuedlessons.com/2008/01/garlic-programmers-for-silver-code.html"" target="_blank" rel="noopener noreferrer">Valued Lessons]
The author thinks "yes" and I agree. I alluded to this in my original post, but consider this curve:
This curve -- the cost of a change in software increases exponentially over time -- was gospel in the world of software development until less than a decade ago. It was absolutely accepted that, essentially, as the artifacts of software development (requirements, documentation, and, of course, source code) grew in size and complexity, the cost of making a change became ever-higher. In other words, as value grew in more-or-less linear form (one more feature), complexity grew in a non-linear form (like compounded interest).
About a decade ago, Kent Beck said "What if that assumption is wrong? What if we could have a curve like:
How would our processes and artifacts have to change to make that come about?"
And his conclusion was "Yes, we can achieve that second curve," by the processes that he called "Extreme Programming."
(One of the reasons why I was so heated in "No Silver Programmers" is precisely because the canard of "5% 20x productivity" not only accepts but exaggerates received wisdom. Just as Beck changed the industry by questioning the received wisdom of exponential cost increases, we cannot afford to perpetuate the myth of super-programmers.)
The way to achieve that second curve (which we can call the "agile cost curve") is, ultimately, to have a "silver codebase." (Well, a silver "artifact" base, because you have to do documentation and training and all of that stuff.) If the complexity of your codebase is growing non-linearly, no programmer (no matter their linear multiple of base productivity) can give you that second curve.
The point is that no heroic performance can change the shape of the exponential rise in cost over time. Tool choices don't change the shape either. What changes the shape of the rise in cost over time are practices.
So, the question becomes "How do you develop and maintain a silver codebase?" And it's widely believed that we have some answers to that:
- Refactoring (continual rewrites of the codebase rather than simple accretion)
- Incremental delivery with shorter timeframes (feedback and validation rather than the risk of diverging concepts)
- An emphasis on quality during development (increased cohesion, decreased coupling, improved project guidance)
- Preference for working code over documentation
Of course, practices are dependent on people -- all the people on the team. To me, a good programmer is one who contributes to the practices that maintain a "silver codebase" -- no matter how quickly they write code! Bad programmers are those who don't care about the quality of the codebase, either due to:
\<
ul>
Arrogance ("Oh, that's not a problem. I can fix that in a couple minutes." "I just pulled an all-nighter!")
Lack of discipline ("Works on my machine!" "I'm done when I see my feature run the first time")
The wrong temperament (delete a loop to hoist a variable)
In addition, the quality of the programmers contribute additionally to the interpersonal dynamics of the team, likelihood of a disastrous miscommunication, etc. So, the interesting question then becomes "How do we maintain that second curve in the face of bringing in new developers?" In recent posts relating to programming talent, I know I've come across as a hard-ass (even though I'm a sweet guy, love my dog, wave people in at intersections, etc.). That's because I've reluctantly concluded that the "agile cost curve" is not stable in the face of poor hires.
In an agile team, there is a great emphasis on individual responsibility. We all learn new practices. We all make mistakes. We all break the build. In such a team, an irresponsible developer (not a slow developer, not an inexperienced developer) can subvert the entire process. And the result, in my experience, is that the "agile cost curve" can jump right back to the classic, exponential cost curve.
\<a href="http://www.knowing.net/PermaLink%2cguid%2cf6755acf-e8df-4f32-8d53-39b9a01992f5.aspx"" target="_blank" rel="noopener noreferrer">Bad programmers are not good programmers who are slow. They are actively counter-productive to the team.