The Quest for Simplicity

1. The Social and the Technical

Philosopher Giles Deleuze said that technology is always social before it is technical. If this phrase is short and cryptic to you, let me explain it with an example: The technology to have fully automated pizza restaurants has been around for ages. They were even a fad in the 50s. These fell out of style for lots of reasons but there essentially was no social need for these. People wanted human contact. With no overriding social need for this technology, it has not found widespread adoption. In a similar fashion, the industrial revolution could not fully begin until the social process of land enclosure kicked off. Technology does not move forward in a linear tech-tree like fashion – there must not only be demand for it, but the necessary social conditions need to exist for the development to be planted. Purely technical considerations are only one half of the equation. This applies to the design and structure of our technologies too. There is a law in software that the structure of programs will inevitably come to mirror the structure of the organization that made the program. This is a perfect illustration of Deleuze’s remark.

How does this apply to the present problem? The complex design of computers and the programs they run is a result of social conditions and decisions made by people, not the intrinsic nature of computing. Users are not too stupid to understand tools. The archetypal tool is the hammer. Not everyone can use one well, but every able-bodied person can use them to some extent and certainly understand them. Even some animals can understand this type of tool. I think there’s two reasons a hammer is easy to understand. Firstly, you can see all of its parts and how they work together at a glance. Secondly, the hammer extends and enhances an existing function of the human person – namely the ability to hit things hard and precisely. Not every tool can be like this, but a lot of the best tools are. There’s an amazing amount of things you can do with a hammer too. If you watch an expert hammer nails, you’ll marvel at the techniques they’ve discovered – yet no one needs such techniques to use a hammer successfully. A good hammer could hurt someone, but only if it is misused. This is a perfect illustration of Alan Kay’s principle that “simple things should be simple, complex things should be possible.”

The opposite of a hammer is the magic wand. The magic wand can do absolutely anything if you know the right incantation – but to the untrained eye it might just look like a broken hammer. The magic wand can also be highly dangerous in unexpected ways – if you mispronounce one syllable, you might turn into a frog. The Sorcerer’s Apprentice also comes to mind.

Most computer programs are a lot more like the magic wand than the hammer. We speak postively of programs “magically” working or doing things “automagically.” AI is the ultimate magic wand tool and we even use a “magic sparkle” symbol to represent it. I think we ended up in this place because the alternative to software working “magically” frequently is software not working at all. As soon as I boot up my computer, a lot of magic happens that I only somewhat understand. Devices initialize, memory tunes up, and soon I’m greeted with a desktop, the graphical user interface that creates a whole magical realm to insulate me from the complexity underneath.

Certain brands of hacker think the GUI is the enemy and that we should all go back to typing commands into terminals. I use the terminal every day and prefer it for many tasks but I could not disagree more that it simplifies things. The terminal is the ultimate magic wand. Terminal commands and scripts are spells and spellbooks. Command-line interfaces are not discoverable unless you already know a few spells. Danger is a keystroke away. They will always have a place in computers, but they aren’t a good UX overall.

GUIs in modern systems are a step in the right direction. They attemptto make the program and its workings more visible and discoverable. WYSIWIG editors like Microsoft Word are a good example of this – what you type on the page is what you see when you print it out. As anyone who has used these programs can testify, they are far from perfect – especially as you stray from the happy path. I think that the concerns of a user are different from those of a developer. Because we view things from our own level of abstraction, things that are immensely complex (like iCloud) can seem very simple and even easy to a user because they “just work.” I think the desire to have things “just work” is a noble one. The problem is when the metaphors and abstractions we use to make things easier are poor and make things worse for us, either by preventing us from doing waht we want to do or by misleading us.

I think it’s worth stepping back and talking about complexity again. There’s no single sense of complexity, other than the information-theoretic sense. Complexity is also always relative to a certain level of abstraction. If you look at a hammer from a sub-atomic level up, you have a complex tool indeed – but we don’t think about that in our day-to-day life nor do we need to. We abstract away that complexity, or simply don’t know about it. The problem introduces a level of intrinsic complexity. Some problems are fundamentally hard. That creates the lower bound of complexity for our tool. The level of mismatch between the tool and the problem you are trying to solve introduces extrinsic complexity. There will always be some amount of this. And of course, different tools may make some aspects of a problem simpler and some aspects harder, but that kind of tradeoff is a discussion for another day. Lastly, since almost all abstractions leak, some extrinsic complexity also gets introduced by our abstractions. An example of this is the hammer’s handle: it isn’t an indestructible thing, it’s a piece of wood – wood can break. That’s a consideration you have to take into account when using a hammer. The lower level complexity of the composition of the tool leaks up to the higher levels.

Applying this to computers, the word processor is a complex problem and it has complex solutions. a WYSIWIG editor is probably the best general way to do it, and it certainly makes it “easy” to get started using a word processor, so the problem-solution fit is OK I guess. A lot of external complexity bubbles up through the implementation that sits on a mountain of oft-leaky abstractions. This gets worse the harder and more complex things we try to do with the tool. If you want to extend a graphical tool, you typically are out of luck or need to know how to program it yourself – assuming the program’s source code is even available. If you want to use a CLI tool, you’re probably already a programmer of some type. This begs another question, why are users and programmers two separate classes?

This is also not because programming is so hard – it is hard – but it doesn’t always have to be. The world’s most popular programming language/development environment is probably Microsoft Excel. This is despite the fact that many of its users do not realize that they are programming and developing applications. It wins on a lot of counts. It’s highly visible – all of your application state is visible in cells of your spreadsheet. Formulas can be created visually. People create entire applications in Excel without even realizing that’s what they’re doing! And in the simplest cases, users never have to even use those features of Excel. Excel loses on a lot of other counts – it’s also built on a massive abstraction, it is not the right tool for many jobs, and a complex app in Excel can be an outright monstrosity. But in Excel, we see an example of a popular, massively useful program where the distinction between being a “developer” and being a “user” is blurred.

This is a lot like one of my favorite programs – emacs. Emacs is at heart, a text editor. The thing that make emacs special is that it’s highly extensible. Some people do almost all of their computing tasks, from reading their email to monitoring system performance, to browsing the web, all from the comfort of Emacs. This provides a very nice, consistent interface – the same bindings and idioms remain available across all of your emacs apps. Almost everything in emacs is self-documenting too. The source-code of almost any aspect of emacs can be quickly jumped to, modified, and reloaded without having to restart emacs. You have an immediate feedback loop between the application and the changes you make to it. If you don’t like the behavior of an existing mode or function in emacs, modifying it is absurdly simple relative to other programs where this might involve forking whatever plugin isn’t working as you like, recompiling/reloading it, etc. Emacs is in part complex because of this. But I used emacs for many years to do all my programming, write my senior thesis in philosophy, etc. without ever needing to reach for these advanced features. Simple things are simple, complex things are possible.

The Smalltalk environment shows us what a fully graphical, discoverable, and programmable user interface might look like. If you haven’t heard of Smalltalk before, try out Pharo Smalltalk sometime, really. It’s like a desktop, but if something doesn’t work how you want it, it’s easy to click into it, see how it works in usually just a couple lines of easy to read code, and just change it! Sometimes you could just click and drag elements around, rotate them, etc. in ways you might have always wished you could in other environments. There’s a lot of magic abstraction in these environments too, but there are always tradeoffs.

I think you could call these kinds of environments “magic hammers.” Like the magic wand, they can do almost anything – and are sometimes fragile. Like the hammer how they work and how you ought to use it is mostly clear and advanced use emerges out of simple use. I think the computer will always be a little bit “magical” but I would prefer to have a magic hammer than a magic wand. There may be metaphors and abstractions, but these metaphors aren’t illusory – they go to the roots of how the system works. The reason that magic wands won, and continue to win, is not because users are all lazy and stupid. I alluded earlier to social conditions and decisions made by people that lead to the present state of computing, and we can now begin to explain those reasons.

The first reason is that the people who paid for and drove the design of the first major computer systems were massive bureaucratic organizations: governments and big corporations. Computers were massive, expensive, and difficult to use. In many respects they were much simpler than modern computers, but their ergonomics were quite bad (punch cards, teletypes, etc.) but it’s curious how such computers resemble the organizations that built them – large, slow, centralized, etc. And these computers generally had one task – carry out the business rules of the organization. Hardware was the product, and customers frequently wrote their own software – which in some ways was good for users, but it also ensured that it was the territory of the high priests of the machine, not the common man. More often than not the users of computers were developers. Early non-specialists might look at reports made by computer users, but not themselves be users of these machines. It just wasn’t feasible nor necessary for everyone to learn the spells. This set the model, which we tried to build better environments on top of.

A second reason is the rise of proprietary software as a business model. Even in the early minicomputer/PC era, users were still expected to be programming a lot of their own software. Hardware was the primary product that companies like IBM were selling. When people (Microsoft) started to figure out you could sell software this started to change. Teach a man to fish, and you’ll get paid for a day – sell a man fish and you’ll get paid every day. Microsoft was filling a real business need – if software (and therefore, computers) could be made more accessible and monetized There was a lot of money to make, and Microsoft’s explosive growth was proof of that.

Before faster internet it was frequently necessary to provide the actual source code of programs in order for users to run them. Sometimes the most efficient way to send a program to someone was to print out the source code, mail it, and have them type it in to the computer! This meant that software was always in principle extensible by the user and every program could potentially be a magic hammer for the power user. Every video game mod scene is a testament to the value that extensibility adds for users even in a proprietary environment. But if other people (and therefore businesses) can create value for users by using your program without you being able to take a cut, that’s a threat to a software licensing business model. This didn’t prevent Microsoft from creating extensible software or even from its embrace of a certain kind of open source software in recent years, but it once again sets a

Lastly, it can be difficult to provide support and to consistently control a more extensible and open software environment. With great power comes great responsibility, and some users can’t be trusted with that. In a business environment, you need to be able to control and limit your employees computers to protect your organization. Windows is quite good at this, and yet people use the same OS for personal computing. Another aspect of limiting extensibility and control is support – if every user’s system is different, perhaps extremely different, customer support and troubleshooting can be a nightmare. Lots of businesses don’t want to deal with that and neither do their users. This is usually where we would blame the users for being stupid and ruining everything by making computers appeal to the lowest common denominator, so we get more walled garden environments like the Chromebook, IPhone, blah blah blah.

The real problem here is that we solved both of these concerns with the same method: the security concerns of large companies that want to avoid having to rely on training their employees, and the everyday concerns of personal computing. This method is to limit and railroad users and create poor user interface metaphors to make things “easy” for them. But at least in the personal computing space, the problems can be solved with more not less freedom. The engineering decisions we took to limit the axes of motion available to a user, like monolithic kernels, OneDrive, app stores, etc. are a topic others have covered, but these social conditions precede those decisions, they are not the result of them.