Richie and Jobs
© 13 Oct 2011 Luther Tychonievich
Licensed under Creative Commons: CC BY-NC-ND 3.0
other posts


A reflection on two giants of computing.


Last week saw the death of two of the biggest names in computing: Dennis Richie and Steve Jobs. Big names for completely different reasons, so much so that saying them in the same breath seems… a bit out of place. I’m neither a biographer nor an expert, but I thought it appropriate to give my thoughts on some of what made these two such giants.

A Brief Overview

Steve Jobs was a face and a manager. As far as I know, he was close to uninvolved in all of the things that became attached to his name. From the Apple I to the iPhone 4, as far as I know he contributed neither engineering nor programming to any of the products attached to his name. But they are attached to his name: Jobs is the most popularPopular in both plebian spread and general admiration. face of computing to date.

Dennis Richie was a doer. He did two impossible things early on: he designed the C language, an ugly, quirky, but hardware-agnostic systems programming language; and he co-authored Unix, an ugly, quirky, but hardware-agnostic operating system. It is hard to overemphasize the importance of these two tasks. I am personally unaware of any consumer product anywhere that both has a chip in it and does not use C or its derivatives. I’d be surprised if anything other than Windows Frankly, I expect to find a lot of Unix in modern Windows builds, too, but that’s just a guess. lacks some part of Unix or a related *nix core.

Attempt the Impossible

Dennis Richie did what no one else thought possible. This is, in point of fact, quite common; it’s one of the reasons you have students writing so many papers in academia: they’re too young and inexperienced to know not to achieve the impossible. It is the genius of engineering: you point a human at a problem and they magically find a solution. It doesn’t really matter if a solution actually exists; they’ll simply tweak the problem definition until it does. And, at some level, the more constraints you put on them the more creative they become at finding things that aren’t constrained.

Steve Jobs made others do what they didn’t think possible. When other companies were giving their engineers whatever freedom they wanted, Jobs was coming down with arbitrary and high-handed constraints: “‍you can only have one button‍”, “‍I don’t want to be able to hear my computer running‍”, etc. Jobs was creating the kind of environment where engineers have to be creative to survive.

There is one element of genius both appear to have shared: they picked good constraints. It’s not immediately apparent why some of them were good; indeed, some (like a 1-button mouse or a null-terminated string) have been identified as mode bad than good in hindsight. But in the end, the reason C and *nix and iWhatevers are successful is a mix of the genius that arose from the constraints and the desirability of the constrained systems themselves.

Go and do thou likewise

While it is unlikely that any one of my readers will be as successful as either of these two giants, might I suggest how each might follow in the footsteps of these two men? That suggestion is simple and two-fold: don’t compromise on constraints you care about, and don’t expect perfection today.

Perhaps some examples. If you like arched ceilings, ask the architect to draw up plans that have an arched ceiling in every single room. If you like a book with dialogue, set a limit like “‍80% of the words in each chapter is dialogue‍” and write the whole book. Expect the result to be quirky and not really usable, but don’t fret it, call anything that meets the constraints a success. Crisp limits are best, even essential in this. There should be no doubt whatever if you met them or not. And out of that design will come significant portions of a result that are truly worth using and that would never have arrived without the constraints.

But why would such a thing work? Frankly, I don’t know, but in my experience it does. When I set out to design a programming language just for fun it came out abysmal; when I went to design one with three painfully-tight self-imposed constraints I ended up with a language worth sharing and publishing. When I write free verse I usually get drivel, but add in a meter and rhyme and I can often pull halfway-decent poetry from half-baked ideas. Tell me to write a blog and nothing happens, but add a five-day-a-week constraint and out pops the very text you are reading.

There are limits to what can be done; my series on theory will address some of them in future weeks. But in my experience, the main obstacle to getting things done is not those limits but rather the lack of additional constraints.

For some reason, throughout writing this post I’ve been reminded of three stanzas from a rhyme by Hillare Belloc from his book More Beasts (for Worse Children), pages 47–48; perhaps that poem shall make for a fitting close.

The Microbe is so very small
You cannot make him out at all,
But many sanguine people hope
To see him through a microscope.
His jointed tongue that lies beneath
A hundred curious rows of teeth;
His seven tufted tails with lots
Of lovely pink and purple spots,
On each of which a pattern stands,
Composed of forty separate bands;
His eyebrows of a tender green;
All these have never yet been seen—
But Scientists, who ought to know,
Assure us that they must be so….
Oh! let us never, never doubt
What nobody is sure about!

Looking for comments…

Loading user comment form…