The original study that found huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968).
This study has been repeated at least 8 times over 30 years and the results have not changed! (see below)
Sackman et al studied professional programmers with an average of 7 years’ experience and found that:
- the ratio of initial coding time was about 20 to 1
- the ratio of debugging times over 25 to 1
- program execution speed about 10 to 1
- program size 5 to 1
Think about that for a minute...
That is the worst and the best programmers made distinct groups and each group had people of both low and high experience levels. Whether training helps developers or not is not indicated by these findings, only that years of experience do not matter in the aggregate. If training does matter then very few developers are getting trained.
Without considering legality, it is simpler to get rid of expensive poor performers and hire good performers with few years of experience!
This does not mean that training does not make a difference for some people. What it means is that unproductive people tend to stay unproductive over their entire career.
Results Have Been Confirmed for 30 Years!
In years since the original study, the general finding that "There are order-of-magnitude differences among programmers" has been confirmed by many other studies of professional programmers (full references at the end of the article):
- Curtis 1981
- Mills 1983
- DeMarco and Lister 1985
- Curtis et al. 1986
- Card 1987
- Boehm and Papaccio 1988
- Valett and McGarry 1989
- Boehm et al 2000
Technology is More Sophisticated, Developers are not
- we have better computer languages
- we have more sophisticated technology
- we have better research on effective software patterns
- we have formal software degrees available in university
That means that there is some other x-factor that drives productive developers; that x-factor is probably the ability to plan and make good decisions.
- laying out code pathways
- packaging functions into classes
- packaging classes into modules
Bad developers just 'jump in'; they assume that they can always rewrite code or make up for bad decisions later. Bad developers are not even aware that their decision processes are poor and that they can become much better by planning their work.
When have you gotten time to go back and fix suboptimal decisions?
Solution hinted at by Watts HumphreyWatts Humphrey tried to get developers to understand the value of planning development, and making decisions in the Personal Software Process (PSP) for individuals and the Team Software Process (TSP) for teams. An analysis of over 18,000 projects demonstrates that1:
The findings suggest that the best way to rehabilitate a poor developer is to teach them how to make better decisions.
- Productive Developers are Smart and Lazy
- Are You are Surrounded by Idiots? Unfortunately, You Might be the Idiot...