One of my enduring personal aspirations is to immerse my life in a universe of self-built, self-hosted tools, at least as far as software tools are concerned. In the lore of self-hosted software tools, perhaps no story figures more heroically than the history of UNIX, the operating system architecture on which most of the Internet and most of the smartphone revolution was built.
The human side of UNIX’s origin story is legendary on its own. Ken Thompson, the original instigator of the project, basically crafted a subtle lie to the Bell Labs management to get a machine on which he could write the operating system, and wrote the first version of UNIX in three weeks, apparently while his wife was away on vacation. It was originally written for the PDP-7, in a moderate amount of assembly, and iterated upon a few times in the following years to get to the ur-UNIX as we know it – the version written in C published in a paper I included in my list of notable papers about computing last year.
I spent this morning reading that original UNIX paper from Ritchie and Thompson titled The UNIX Time-Sharing System. The whole paper is well-written and articulate with details about the state of the art of computing of the era showing through beautifully, but I was struck by the conclusion of the paper, where the authors cite why they think UNIX was so well-received. Of course, at the time of publication, neither of them anticipated the forthcoming explosion of computing that would be fueled by UNIX-based systems, but their account of their success holds up nonetheless:
Perhaps paradoxically, the success of UNIX is largely due to the fact that it was not designed to meet any pre-defined objectives. […] Our goals throughout the effort, when articulated at all, have always concerned themselves with building a comfortable relationship with the machine and with exploring ideas and inventions in operating systems. We have not been faced with the need to satisfy someone else’s requirements, and for this freedom we are grateful.
Unlike most systems of the vintage that were commissioned by large companies for commercial uses, UNIX was created out of programmers’ desires for a better tool and workspace for programmers like them. And “paradoxically,” as the authors note, this approach resulted in a system that succeeded nearly universally.
To conclude the paper, the authors lay out three specific reasons that contributed to the success of UNIX. Reading over them, I thought they held a lot of value as timeless principles for building great tools of all kinds, so I wanted to enumerate and comment on them here in relation to some of my own principles.
In the order of their presentation, the three are:
1. Design for makers
UNIX was an operating system designed for programming.
First, since we are programmers, we naturally designed the system to make it easy to write, test, and run programs. The most important expression of our desire for programming convenience was that the system was arranged for interactive use, even though the original version only supported one user.
An operating system is a kind of tool that is the workspace for all your other work. It defines the outer limits of what you can do within it. A batch system for computer use, where a programmer would submit jobs to be run and get answers later, was the norm at the conception of UNIX, but the developers went against this trend for a (now ubiquitous) interactive design.
This insight is tied closely to the fact that the inventors of UNIX weren’t developing a product to meet requirements, as a tool to accomplish a single task. They were building a tool they actually wanted to use, and tried to build “a comfortable relationship with the machine” as they noted in the paper.
It turns out that changing the relationship between the maker and the tool, a purely qualitative change, has a dramatic impact on the kind of work you can do with it, and how productive you’ll be using it.
2. Embrace constraints
Unlike the commercial efforts of the day backed by deep corporate pockets, the UNIX inventors couldn’t spring for expensive top-tier machines.
Second there have always been fairly severe size constraints on the system and its software. Given the partiality antagonistic desires for reasonable efficiency and expressive power, the size constraint has encouraged not only economy but a certain elegance of design.
Here, I think the authors articulate a non-obvious benefit of design constraints. They contend not only that it led to more efficient design, as you’d assume, but also that it led to better, more elegant design of the system. Elegant design makes it easier to change or add components over time as the tool needs to be adapted for broader use cases. Constraints are helpful in the pursuit of more elegant design because they make you think twice about your design decisions, because every tradeoff is more consequential. As an obvious bonus, a tool that works well because it was created under constraints will work even better without those same constraints.
3. Self-host and self-modify
Perhaps most important to me of all three, UNIX quickly became a tool for developing later versions of UNIX.
Third, nearly from the start, the system was able to, and did, maintain itself. […] Since all source programs were always available and easily modified on-line, we were willing to revise and rewrite the system and its software when new ideas were invented, discovered, or suggested by others.
Self-hosting – using a tool to build another instance of itself – is interesting from a technical perspective. But the more important benefit that Thompson and Ritchie point out here is that self-hosting made self-modification easier. You could be using the system, find something that didn’t quite work right, and because the source code was right on the system, you could simply add or modify it as you needed. It’s not just that this was possible, but that this was right there, so available, that people were “willing to revise the system” as convenient.
This is so clearly the best way to build a tool that can grow around the way you use it, over time, around your specific workflows. The UNIX environment, a tool remarkably well-suited to the software development task, didn’t emerge from nothingness in its final form. Its initial version was bare, but moldable. And the first users added utilities and modified its behavior to work the way they needed, because modification was easily available.
I think these principles apply universally not just to software projects, but to the process of building all kinds of tools, from online community platforms to note-taking methodologies to hand tools.
This is the way to build tools. Under the right conservative constraints that inspire elegant design; designed for creative power, not for a task; and under constant, active use that leads to the tool taking shape around the silhouette of the workflows it needs to serve.
← Taylor Swift: a venture investment thesis
I share new posts on my newsletter. If you liked this one, you should consider joining the list.
Have a comment or response? You can email me.