Doing One Thing, Well: The UNIX Philosophy

By Bryan Cockfield

The Unix operating system has been around for decades, and it and its lookalikes (mainly Linux) are a critical part of the computing world. Apple’s operating system, macOS, is Unix-based, as are Solaris and BSD. Even if you’ve never directly used one of these operating systems, at least two-thirds of all websites are served by Unix or Unix-like software. And, if you’ve ever picked up a smart phone, chances are it was running either a Unix variant or the Linux-driven Android. The core reason that Unix has been so ubiquitous isn’t its accessibility, or cost, or user interface design, although these things helped. The root cause of its success is its design philosophy.

Good design is crucial for success. Whether that’s good design of a piece of software, infrastructure like a railroad or power grid, or even something relatively simple like a flag, without good design your project is essentially doomed. Although you might be able to build a workable one-off electronics project that’s a rat’s nest of wires, or a prototype of something that gets the job done but isn’t user-friendly or scalable, for a large-scale project a set of good design principles from the start is key.

As for Unix, its creators set up a design philosophy based around simplicity from the very beginning. The software was built around a few guiding principles that were easy to understand and implement. First, specific pieces of software should be built to do one thing and do that one thing well. Second, the programs should be able to work together effortlessly, meaning inputs and outputs are usually text. With those two simple ideas, computing became less complicated and more accessible, leading to a boom in computer science and general purpose computing in the 1970s and 80s.

(Not disrespect for the IBM 360; we just needed a cool photo of an old computer.)

These core principles made Unix a major influence on computing in its early days. Unix popularized the idea of software as tools, and the idea that having lots of tools and toolsets around to build other software is much easier and intuitive than writing huge standalone programs that reinvent the wheel on every implementation. Indeed, at the time Unix came around, a lot of other computer researchers were building single-purpose, one-off monolithic blocks of software for specific computers. When Unix was first implemented it blew this model out of the water.

Because of its design, Unix was able to run easily (for the time) on many different computers, and those computers themselves could be less expensive and less resource-intensive. It was known for being interactive because of the nature of programs to be relatively small and easy to make use of. Since all of these design choices caused Unix to become more intuitive, it was widely adopted in the computer world. Now, this model isn’t without its downsides, namely efficiency in some situations, but the core idea was good and worked well for the era.

Worse Is Better

Another interesting idea to come out of the computing world around that time was the saying “worse is better“. Although this idea wasn’t a direct relative of the Unix philosophy, it’s certainly similar. The idea references the fact that additional features or complexity doesn’t necessarily make things better, and a “worse” project — one with fewer features and less complexity — is actually better because it will tend to be more reliable and usable. Most of us can recognize this idea in at least one of our projects. We start work on a project but midway though the project we decide that it should have another feature. The feature creep causes the project to be unusable or unreliable, even given its initial simple design goal. An emphasis on simplicity and interoperability helps fight feature creep.

Keeping these design principles in mind can go a long way to improving anything you might happen to be working on, even if you’re not programming in Unix. We’ve seen some great examples around here like the absolute simplest automatic sprinkler that does the same job expensive, feature-rich versions would do: water plants. There have also been simple tools that have one job to do and don’t allow feature creep to corrupt the project.

Even large-scale manufacturing processes have benefitted from design principles that are shared with Unix. The eminently hackable Volkswagen Beetle was designed in a way that made it one of the simplest, most reliable vehicles ever made that also had the benefit of having a small price tag. As a result of its durable, simple design and ease of maintenance, it became one of the most popular, recognizable cars of all time and had the largest manufacturing run ever as well, from 1938 to 2003.

On the flip side, there are plenty of examples where not following a simple design philosophy has led to failure. Large infrastructure can be particularly susceptible to failure caused by complexity, as older systems are often left neglected while new sections are added as population increases. While failures such as the Flint water crisis weren’t caused by complexity directly, whenever damage is caused to these systems they can prove extremely difficult to repair because of that complexity. It’s difficult to build large pieces of infrastructure without a certain level of complexity, but simplicity, ease of maintenance, and using good design principles can save a lot of trouble down the road.

Another example of complicated design can be seen in many modern cars, especially luxury brands. The current trend in automotive design is that more features, rather than higher build quality, means more luxury, so upscale cars tend to have tons of features. This can be great on a new car, but the downside is apparent in the repair bills that come after just a few years of ownership. The more features a car has, the more opportunities there are for failure, or at least for hefty maintenance costs.

Even though modern Unix and specifically the monolithic kernel found in Linux are incredibly complicated now, they still retain a lot of the original design philosophy that they had in the early days. This philosophy is a large part of the reason they’ve been so successful. The idea of simplicity and doing one job well is still ingrained in the philosophy, although you can certainly find examples of software that doesn’t follow all of these ideas anymore. Regardless of the current state of modern software, the lessons learned from Unix’s early design philosophy are universal, and can go a long way whether you’re working on software, cars, infrastructure, or simply watering some plants.