In a recent blog post Martin Fowler writes about developer talent & productivity. Fowler’s post is centered around a hypothesis that there are developers that are twice as productive as the average developer. The factor 2 is not the important thing here, it’s not a universal constant or so. It is simply a number that fits well in the example Fowler is using. The conclusion is that due to the costs of communication overhead that comes with a bigger team, paying twice as much for individual developers that are twice as productive is a wise thing to do. Fowler also mentions the positive effects on the code-base that comes with more talented developers. He doesn’t go very deep into this area, which gives me room to elaborate.  

First, it is important to understand that developer talent does not just mean “extra speed”. A talented developer will not produce the same solutions as the average developer, but something better. In many cases this better solution can never be reached without a certain amount of talent. At the extreme, there are solutions that simply cannot be reached without a very high amount of talent; substituting talent with manpower is not an option. 

At the opposite extreme we have tasks where the talented developer will produce roughly the same quality as the average developer, only faster. It is important to understand that this types of tasks are very uncommon – or at least they should be. If the output of a development task is so well-defined that any two developers will end up with exactly the same code, the work should probably be automated in the first place. Which brings me to the next aspect of individual talent: making other developers more productive.     

Looking at productivity only from an individual perspective is a mistake. What matters is team productivity. And this is where it starts to get interesting. Individual developer talent has the potential to boost the productivity of the whole team. For example, talented developers have the capability to develop frameworks and tools, which can boost productivity and software quality a lot. I often hear that framework and tool development should not be part of a typical application development effort. The truth is that there is always needs and room for this kind of development. But sometimes it requires skills that can not be found on the team. And when frameworks are developed without the right level of talent, we’re better off without them. Also, it is a big difference between generic frameworks developed to be used by others, and small application specific frameworks, which are really just the result of the need to remove duplicate code in an application. In my experience a majority of development projects would benefit from more custom tools and frameworks; in such cases, paying for the proper amount of individual talent is money very well spent.    

Better team scalability + more agile teams + better code-bases + pulling off demanding development tasks + making others more productive. To me this is compelling. Still there is a lot of hesitation to pay more for talent. Many (most?) people/organizations don’t seem to be convinced. Some are though; I recently stumbled over XML People where Tim Bray writes:           

“People in the trade will tell you that a good programmer isn’t twice as good as an average one, but many times as good. There’s no meter to measure such things, but I’ve worked for, and with, and managed, a lot of them, and my experience is that the performance of working programmers varies by a factor of at least 100.”

Food for thoughts…