Developer Productivity Mean vs. Median

 10                                            .
  9                                          . .
  8                                      . . . .                                     
  7                                  . . . . . .
  6                              . . . . . . . .
  5                          . . . . . . . . . .
  4                      . . . . . . . . . . . .                         
  3                  . . . . . . . . . . . . . .             
  2              . . . . . . . . . . . . . . . .
  1          . . . . . . . . . . . . . . . . . .
  0      . . . . . . . . . . . . . . . . . . . .
        ___________________+_+___________________
         1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2
                           0 1 2 3 4 5 6 7 8 9 0
  

OK, first a little remedial math: mean is defined as the mathematical average of a series of numbers. For the set of numbers above, the mean = 4.55. The median is defined as is the number defined as lying at the midpoint of a sorted number series, which is 5.5 in this example.

Why in the world am I talking about this? Well, it pertains to developer skills. You see, really good developers are much more productive than average ones (this has been documented in several places, including the Mythical Man Month and Joel). In fact, some statistics say that really good developers are orders of magnitude better than poor ones.

Consider this version of the graph:

10                                            .
 9                                          . .
 8                                          . .                                     
 7                                          . .
 6                                        . . .
 5                                        . . .
 4                                        . . .                         
 3                                      . . . .             
 2                                  . . . . . .
 1                    . . . . . . . . . . . . .
 0            . . . . . . . . . . . . . . . . .
       ___________________+_+___________________
        5 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 1
          0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0
                                              0
 

For this one, the mean = 2.7 and the median = 2. If the height of the graph line represents programmer productivity, the second one is closer to reality.

So what does this mean to development? Managers used to think that this is a nice straight 45 degree angle, and that even if you can't get the best and brightest, you still get usefulness out of mediocre developers. But building software isn't like digging a ditch. Even poor ditch diggers can make a hole. In software, what you (and others) write today becomes the foundation for tomorrow. If you have bad developers building your foundation, the really good developers have to go back and fix it before they can build more useful stuff. Hiring mediocre developers (or just average ones) slows project velocity. Couple this with the fact that adding people to a late project makes it later, and you can understand why most enterprise development moves at a glacial pace. Building software in the large with lots of average developers emphasizes two negative project metrics: trying to scale by adding people and that average developers produce code on the average scale. But the truth is more like the lower graph: overall productivity is dragged down to the median level, not the mean level.

An entire industry has been built to solve this problem. It was thought that you can fix this problem in two ways. First, build restrictive languages that keep bad developers out of trouble. But, Glenn Vanderburg has a dead-on quote that reflects the reality that he (and I) have seen on projects: Bad developers will move heaven and earth to do the wrong thing. Command and control computer languages aren't like the governor on a car, forcing you to drive more slowly and thus more safely. At the end of the day, weak languages slow down your best developers and don't prevent the bad and mediocre ones from writing horrific code.

The other attempt at fixing this was to take restrictive languages and build really smart tools to help developers generate code faster. This is the classic implicit sales pitch for Visual Basic: no one can hurt themselves, and you can hire cheaper developers to write your code, without paying a good salary to those annoying software craftsmen. It is widely known that Microsoft internally calls mediocre developers "Morts" and targets them with some of their tools. Of course, this doesn't apply to all Visual Basic developers and not to good developers in the .NET space. But it is the reality that this dual strategy is the way vendors have sold tools for the last couple of decades.

And now we see that it doesn't work. Part of the ascension of dynamic languages is the realization that the experiment of command and control languages don't make average developer's code any better, and it hampers your really good developers. Why not figure out a way to unleash the good developers and let them go as fast as they can? Ruby on Rails is a good example of using domain specific languages to create a simpler language on top of Ruby for things like ActiveRecord relationships. For everyday coding, you can stay at the high, simple abstraction layer. If you really need it, you can dip below that abstraction level and get real work done in Ruby. For many of the Ruby projects on which I've been involved, using open classes is done strategically, accounting for between 1.5% and 4% of the total lines of code. Yet that surgical use of one of the kinds of meta-programming that Ruby allows eliminates hundreds of lines of code.

So what does all this mean? First, give good developers powerful tools and you'll get higher quality software faster. Second, as an industry we would become more productive if 30% of the existing developers were laid off tomorrow. Having warm bodies doesn't help projects, and having to baby-sit poor developers cuts the productivity of your good developers. Software is too complex to turn into an assembly line manufacturing process, at least for now. Good software developers are still craftsmen, no matter how much that annoys companies that wish that wasn't true.