|Home » Learning Curve » Developers Workshop
The Fourth Rule
It may be mostly unwritten but it's more pervasive than the others.
Brian Kernighan had three golden rules of programming. From the epilogue to his legendary 'Software Tools' series. They're the foundation of all we do.
- Keep it simple.
- Build it in stages.
- Let someone else do the hard part.
But there's a fourth rule rarely articulated that still and all has as much an influence on computer science as any of the above three. Or more. Or more than all three taken together.
Throughout Brian's extensive writings this fourth rule, albeit never articulated directly, comes shining through again and again.
Brian is an incredibly clear thinker. He never rushes to judgement. He doesn't fall prey to featurism. He doesn't change things in proven code on a whim. He's also the one who first quipped the following.
First make it run, then make it run fast.
He's also attributed with the following bit of wisdom.
Controlling complexity is the essence of computer programming.
And the following.
The most effective debugging tool is still careful thought coupled with judiciously placed print statements.
The fact that Unix is considered not only an operating system but a way of thinking is mostly attributable to Brian as well. Together with Doug McIlroy Brian's responsible for the status quo of software development today.
After the initial work at Bell Labs Unix moved from Murray Hill downstate to the Unix System Laboratories and eventually made its way to institutions of higher learning and finally into commercial enterprises. But the goal of Unix and its software development remained constant.
It's a collaborative effort that today powers most of the world's Internet servers and totally dominates in system design and in programming both. Microsoft's MS-DOS borrowed heavily from Unix as does their VMS clone NT; Linux is a 'back to the basics Unix'; FreeBSD, NetBSD, and OpenBSD are all based on work by Bill Joy and others at Berkeley where Ken Thompson did his sabbatical; the Berkeley sockets which power the TCP/IP of the Internet are all written with Unix in mind; and so forth.
It's a great collaborative effort. Contributors from a great many corporations and institutions contribute code, add to the legacy, find their code vetted and improved. Eric Raymond says the Internet itself is the single most accessible example of the virtues - and the success - of this approach. And he's right.
And what's important here is all these 'giants' implicitly obey the Fourth Rule.
Apple don't obey the Fourth Rule. Odds are they've never heard of it or felt it. Chances are also good they don't know anything about the other rules either. Apple are a commercial enterprise - the infrastructure of the Internet and of programming in general are built without that domain.
What's worse is Apple are notorious for not collaborating. Secrecy is their middle name. They don't take to sharing with others and don't like to take the advice of others either.
And in the void that results they fill things with featurism. Just like Microsoft.
For it's just not good policy to forge ahead and branch from accepted wisdom. Wisdom that dictates not only caution but a need to test new ideas not in the laboratory for a few days but extensively over time.
New ideas in the world of Unix can be considered good ideas if they're universally adopted and acknowledged by all. The world of Unix - the world of computing - can only benefit by collaboration.
New ideas that don't catch on are quite simply not good ideas.
How many times have Microsoft announced technological breakthroughs only to be laughed at by the programming community because they've been in the world of Unix all along? Microsoft keep falling into this trap because they simply don't keep tabs on what the rest of the community are doing. And nobody outside the cathedral is particularly interested in their 'technology' and the results of their capricious 'research'.
Microsoft's is not only a closed system - it's also a closed off system.
And the same applies to Apple.
Commercial software as it works today is a relatively new phenomenon. Back in the mists of time when there was only one computer company it was hardware you bought. Not software. The software was free. And although you needed the software - and the hardware to run it on - what you really needed was the support.
You didn't worry about 'coming versions'; you didn't have to listen to the hype of 'this release is in the pantheon', 'this is the best program ever written', 'over three hundred new features', ad nauseam. Clients bought support and vendors sold commitment.
New version? It's there. No fanfare. Test it a bit, put it in production. Robert Tappan Morris and Paul Graham made a $45 million product in the Internet era this way. Versions? New releases? Just upload the code!
Commercial software is planned obsolescence. You don't sell support; you wouldn't know how to provide that support anyway; instead you keep introducing more and more doodads (and changing the ones you already have) to not only make your new versions look better but also to make your old versions look outdated and 'uncool' by comparison.
Software by its very nature is not the latest new improved margarine that's so good you can't believe it's not butter. Software by its very nature is not what you find on a catwalk in Paris. Software is a synthesis of good ideas again made simple so as to provide a solid foundation for further work.
Whenever possible we will build more complicated programs up from the simpler; whenever possible we will avoid building at all by finding new uses for existing tools, singly or in combination. Our programs work together; their cumulative effect is much greater than you could get from a similar collection of programs that you couldn't easily connect.
Whenever things start to get too complex; when there's an ostensible fetish for change only for the sake of change; when things change too rapidly over a short time; that's when you're in trouble.
You're off the beaten path; you're on your own. And in the world of collaborative computing you're never supposed to be on your own.
Everyone knows debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it - how will you ever debug it?
Eric Raymond: The Art of Unix Programming
Linköpings universitet: Programming in C: A Tutorial
Princeton University: An Interview with Brian Kernighan
Kernighan/Plauger: Software Tools
Kernighan/Plauger: Software Tools in Pascal
Kernighan/Ritchie: The C Programming Language
Kernighan/Plauger: The Elements of Programming Style