Increasing programmer productivity

Aug 25th, 2002 by Tony in * commentary, QSM1

Studies of individuals have consistently shown variations of 20:1 or more in schedule, cost, and error performance among professional programmers, so it makes sense that this is the level of variation we see in Pattern 1.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 2

I’ve been thinking about this concept a lot again recently. This sort of figure crops up again and again in all sorts of places. It’s a reasonably well known concept, and reasonably self-evident to anyone who’s worked around enough programmers. So why is virtually no-one interested in the concept?

Yes, you get people writing about “software productivity”, but these tend to fall into two main camps. The first, who usually have something to sell, write about the newest, greatest Silver Bullet that will increase everyone‘s productivity by an order of magnitude.

The second, the more thoughtful consultant types, work hard with companies to smooth all their processes, and slowly move them up the CMM scale, or, in Weinberg’s case, his Six Degrees of Congruence.

But again, this is about raising the company’s level, as the totality of everyone. Although it’s rarely explicit, the implicit assumption is that it’s bad to rely on these “super-programmers”, and you need repeatable processes that work even if you lose your star performer(s). As Dijkstra put it:

Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees. Hence industry rejects any methodological proposal that can be viewed as making intellectual demands on its workforce

Both of these approaches miss the point, in almost exactly the same way. They don’t concentrate on why some programmers are 20 times more productive than others, or whether it’s possible to create more of these star programmers.

Perhaps it’s just that people just don’t know how to cope with this entire concept. Bob Morris, in his keynote at the Emerging Technology conference earlier this year, talked about how in the last 100 years, $1000 worth of computational power has increased by 14 orders of magnitude – an unprecedented scale that people find difficult to conceptualise. But, in most fields of human endeavour, people can’t even conceptualise one order of magnitude. The world record time for running a mile is around 3 minutes 43 seconds. Even an average runner can run a mile in less than twice that length of time. This plays out again and again: the best is maybe only twice as good as the average. The difference between professionals is much less. In Formula 1, where cars go at speeds in excess of 200 miles per hour, the significant difference in lap speeds is often measured in hundredths of a second. (At those speeds we do get our factor of 20 over the human running that mile, but with huge costs and a lot of ‘artificial’ aids that can raise most people to the same levels)

In the workplace it’s not very different. You won’t find a call centre with an two employees, one of whom handles twenty times more calls than another (at the same, or even better, level of quality). Or two secretaries, one of whom can type twenty times more letters than the other.

We’re not used to dealing with these levels of differences between people, so we don’t know to deal with it when it happens.

And, with programmers, it’s hard to actually see it happening – not at the detail level. We know that Fred gets much more done than Barney, and can do most jobs in a fraction of the time, but we can never quite see how. When we look closely, they both seem to do the same thing. There’s no obvious flaw in Barney’s approach, or obvious methodological differences that could be applied. It just seems to happen, so we write it off as just an anomaly.

Managers in “lower” organisations on most of the “quality scales” rely on the fact that they can give the work to Fred, and have it done quickly, whilst always having that nagging fear of Fred moving somewhere else. Manager in slightly more “advanced” organisations know that they can’t rely on Fred, so they work out all their schedules and budgets based on Barney instead. Neither attempts to make Barney as productive as Fred. They may wish he was, but neither think it’s possible.


No Comments