The Tipping Point II

'Make each program do one thing well.'

Doug McIlroy, the godfather of Unix, laid down the law for Ken Thompson and Dennis Ritchie before they got underway. Of his four aphorisms, the applicable one here is the first.

'Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.' [BSTJ 1978.57 p 1902.]

Operating systems are the underbody everyone must be able to rely on. There is no room for featurism or 'just one last thing'. Code has to be strict and even application domains have to be carefully laid out.

It's not quite that way in the world of commercial software. Legendary WordPerfect marketing manager Pete Petersen, totally alien to the art of programming - but not of marketing - firmly believed every release of a software product must outdo its predecessor not only in features but in pure bulk.

For years WordPerfect was practically speaking the only word processor in use on the planet. Gradually it became known as the buggiest.

Microsoft Word was first released around 1985. It was the work of four programmers. Today the programmers on the Word team number well over one thousand, and that's not counting colleagues working on ancillary products such as VBA which are incorporated into the Word 'whole'.

Presently there is a war on between Sun, Microsoft, and Apple for the most features on the end user desktop. None of these features have anything to do with overall or long term performance or usability - they're just more features.

And as the features grow in number and become more and more ridiculous, so does overall system stability decline.

People who like to tinker with programs like features and lots of them. They want to lose themselves in all the options and cool new things they can do. A new program becomes a world they can escape into.

Programs such as Path Finder and BBEdit are overloaded with features. Path Finder has a terminal drawer despite the fact OS X sports a terminal application any program can interact with. BBEdit does crazy things like move the caret to the middle column of the middle row and reverse all the rows. It also sends you off surfing to a URL when the operating system already does it all by itself.

People who have to get a job done are rarely interested in features. They don't have time. Engineers like their tools simple and straightforward - like Doug McIlroy says they should be written. A classic example is the Hollywood IT consultant searching for a program to do one thing for a client. The consultant isn't even worried about stability or cost - but the program has to work a single time and work correctly, after which it can be thrown away.

Professionals require as much stability in their software as application developers require in their operating system. The more their software sticks to the basic tenets the better it will run - and they know it.

It's often said the greatest learning experience when it comes to system design comes from writing a text editor. The basic functions are self-evident (but not necessarily trivial). Manage the caret and input; add functions to navigate through a buffer; add I/O; add search functions. And so forth.

The learning experience comes when you have to add a new feature. Most likely it won't fit well in the current scheme. You have to break the code apart, create new sub-interfaces from previous ones, wire the new feature in - and then test test and test.

IBM used to have a programming language of their own called PL/1. PL/1 was a 'shell' language in the sense that it tried to literally do everything. It admitted of assembler syntax, COBOL syntax, and FORTRAN syntax all at once. The idea was to build something very powerful, but that idea tripped up over its own legs.

It turned out that the language syntax was so comprehensive that programmers could write perfectly correct code that still did the wrong things - it was impossible to cover all three parts of the language at once. PL/1 was an unwieldy tool.

The 'kernel' language C is the antithesis of PL/1. The syntax is extremely finite. Given the possibilities available, the chances are very good that if the programmer screws up the compiler will know it. And yet C is not a poor language for that - on the contrary, it's much more powerful than PL/1.

A neophyte once approached Brian Kernighan with suggestions for the improvement of C. Brian listened politely, was silent for a moment afterwards, and then said:

'Those are all very good ideas. But you don't want to incorporate those into C - C is meant to do what the machine does and do it well. If you veer from that philosophy, you destroy the language.'