Niklaus Wirth’s writing in 1995 is just as relevant today as it was then. Some gold in here:

• 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 significant degree of detail by a single individual, should probably not be built.

• Communication problems grow as the size of the design team grows. Whether they are obvious or not, when communication problems predominate, the team and the project are both in deep trouble.

• Reducing complexity and size must be the goal in every step—in system specification, design, and in detailed programming. A programmer’s 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.

Some of the best programmers I’ve ever worked with wrote the least amount of code.

• To gain experience, there is no substitute for one’s own programming effort. Organizing a team into man- agers, designers, programmers, analysts, and users is detrimental. All should participate (with differing degrees of emphasis) in all aspects of development.

• Programs should be written and polished until they acquire publication quality. It is infinitely more demanding to design a publishable program than one that “runs.” Programs should be written for human. readers as well as for computers. If this notion contradicts certain vested interests in the commercial world, it should at least find no resistance in academia.

I was meeting with an advisor this week and one of his pieces of advice was very similar to this last point: We often get only one shot at a first impression in software, especially for B2B hosted software. Make sure it’s ready and polished up. If we need more time, then take it to build, but don’t rush something out. An “MVP” isn’t a good thing in the B2B space.

(via Daring Fireball)