This paper reads like an old man yelling at clouds, but then, half way through, he simply writes a better cloud. (This metaphor is pretty awkward given cloud computing.)

A Plea for Lean Software, by Niklaus Wirth

In 1985 Niklaus Wirth, fresh off of Pascal, decided that software was too bloated. He placed the blame on two laws:

  • Parkinson’s law: Software expands to fill all the available memory.
  • Reiser’s law: Software is getting slower more rapidly than hardware becomes faster.

“A Plea for Lean Software” was written in 1995, right when software starting to rely on Moore’s law (that processing speeds double every 2 years) to let consumers up with their own bloat. Major software was/is/probably-always-will-be explicitly designed to only be usable on tomorrows computers. My rough-rough-rough understanding is that, of the major companies, only Apple focuses on improving software size, and that’s due to their org chart being organized by function instead of by product.

Anyways, back to the paper.

Wirth wrote an operating system just to prove it could be done in better than anything else on the market.

The result: OBERON.

It took two academic professionals three years. They used a semi-custom-built object-oriented language for the task. That language: also called Oberon!

The whole paper is a blast to read.

Niklaus Wirth concludes with nine lessons learned while building Oberon. There are my favorite:

Two) The most difficult design task is to find the most appropriate decomposition of the whole into module hierarchy, minimizing functions and code duplications.

Five) The belief that complex systems require armies of designers and programmers is wrong. A system that is not understood in its entirety, or at least to a significant degree of detail by a single individual, should probably not be built.

Seven) Reducing complexity and size must be the goal in every step–in system specification, design, and in detailed programming. A programmers competence should be judged by the ability to find simple solutions, certainly not by productivity measured in “number of lines ejected per day.” Prolific programmers contribute to certain disaster.

Eight) To gain experience, there is no substitute for one’s own programming effort. Organizing a team into managers, designers, programmers, analysts, and users is detrimental. All should participate (with differing degrees of emphasis) in all aspects of development. In particular, everyone–including managers–should also be product users for a time. This last measure is the best guarantee to correct mistakes and perhaps also to eliminate redundancies.