Generation Gap in Software Development

A generation gap seems to be forming in the world of software development. True generation gaps are few and far between, so I’m not ready to say that’s what this is, but it’s what it looks like on the surface.

The gap I’m referring to lies somewhere between the typical 60-year-old executives of the old-line computer companies and the typical computer programmers who do most of the actual work of software development and who average about 30 years of age. Beyond the fact that they may work for the same companies and on the same projects, it is hard to find much common ground between the two camps. And each side is ready to blame the other for the all-too-familiar slow going on large corporate software development projects.

The older set says the younger set is disorganized, overconfident, and flaky. They see them moving too quickly and making too many mistakes. But to the younger set, the older set is ill-informed, likes to slow things down with unnecessary rules and procedures, and generally takes computer work far too seriously. For example, they may point to restrictive version control systems that prohibit some necessary testing and delay or prevent fixes for known bugs. In each case, there is a grain of truth in the criticism. In a generation, the breadth and depth of programming talent has increased 100 times, and it’s hard for an old-style executive not to underestimate the talent he’s dealing with, both in his own company and among its competitors. Today’s high school students in 20 countries have better programming skills than the professional programmers of 30 years ago. Management approaches developed in the 1960s and 1970s to draw maximum results from a meager programming staff are counterproductive in a world where there are far more programmers than managers. Meanwhile, the gung-ho younger developer types tend to overestimate the amount of work that needs to be done because they don’t realize how much effort can be saved with a thoughtful, systematic approach to a software project. Techniques such as system flow diagrams and object hierarchies might be tedious, but done correctly, they really can reduce the level of repetition, and thus the potential for error, in a system.

On balance, which point of view works better? If you want to make money, the old-timers’ corporate approach has the edge; old-school software giants such as Oracle, Adobe, and SAS remain hugely profitable and pay their employees well, while most of the new-economy dot-coms have come and gone. But if you want software that works, the new generation of programmers is unbeatable. You can see this in the recent open-source projects that have come together with little or no corporate structure. Products such as Apache, Linux, and Mozilla lead their categories in reliability, even though they were put together quickly with a fraction of the effort of competing commercial products. And so maybe the real story is not the generation gap, but this split between profitability and software quality.

Fish Nation Information Station | Rick Aster’s World | Rick Aster