Karen asks why we, as software creators, haven’t yet learnt about the things that people were writing about more than 20 years ago. This ties neatly into an article I was reading yesterday in the April 1998 issue of Computer by Ware Myers.

Citing figures gathered by himself and Putnam, Myers claims that:

A reality that is not universally acknowledged is that the general capability of software organizations extends over a truly enormous range. The difference between the productivity of individual developers is in the order of 10 to 20 times. The difference between the capability of software development organizations is at least two orders of magnitude greater – 100 to 200 times.

As with most of these figures, the result is based on comparing extremities. However Myers also shows that, on their scale of 33 levels, “an organization now about 5 index numbers below the mean can increase its process productivity by a factor of 5-11 times by improving not to the very top, but to five index numbers above average.”

He offers some suggestions as to ways that organizations could improve, such as establishing the feasibility of a large development task beforehand, citing figures that 65% of 1 Million+ LOC systems are cancelled before completion, as are 50% of 500KLOC systems, and 25% of 100KLOC systems. As Myers says, these approaches “seem fairly obvious, but many software organizations manage to ignore them.”

So, what’s the hang up? Myers cites 5 main reasons why we never learn:

1. Psychological hurdles: we’re resistant to change. Developers in particular are usually keen to get to the “meat” of the task – the actual coding – and hate spending time on messy preliminaries.
2. We don’t know about better ways: Myers kindly suggests that developers might not have had the time to seek out new approaches, whereas I think most developers just don’t have the inclination. However, Myers points out that Business Systems projects see, on average, 10% productivity gains per year, so not keeping up can have quite a large cumulative effect.
3. We’re Gun-Shy: Lots of the “better ways” promoted in the past haven’t delivered on their supposed effectiveness. Why should be believe any other ways?
4. We’ve tried and failed: Even the valid “better ways” are usually not easy to implement; they take champions, time, investment and persistence.
5. We’re stifled economically: we may not have the resources to devote to long-range productivity efforts

Personally I agree more with Karen: programmers love to program. And we love to solve problems. Looking up someone else’s solution just isn’t as interesting or exciting as trying to work through it ourselves. And writing less code? There’s no way that someone else’s code would be as good as, or do all the things that mine would!