A Plea for Simplicity

by Casandro

Somehow, computing seems to become more and more complex.

The couple of dozen of kilobytes needed to boot a PC have turned into a multi-megabyte mess called UEFI, providing the same functionality as Open Firmware at nearly a thousand times the size.  Booting Linux systems is turning from some simple shell scripts to a 250 kB (as of October 2014) mass of C-code.

Even rather simple static websites now are generated on the fly, linking to lots of external JavaScript frameworks.  It's not uncommon today for the HTML code of websites to be larger than screen shots of them.  In fact, even supposedly simple tools like cat or strings have more options than you'd expect.

How can those projects get so big?

Obviously, one of the reasons is that computers become more and more powerful.  You couldn't have 16 megabytes of code just to load your operating system from disk when your whole address space is just a single megabyte.  However, there are also cultural issues.

Computing is now a lot more common.  So companies can now have more people to sell licenses to, which means they can spend more money on developing that software, which means more and more features will be added.  It's similar for noncommercial software.  While in the past someone might have gotten their program published in a magazine or on Teletext (the Austrian broadcaster ORF regularly aired software readers sent in), we now have a vivid FOSS culture.  In fact, it's common for people to earn credits in university and on the job by participating in such a project.  And through various ways we are even able to fund large organizations to undertake the creation and maintenance of huge programs.

Now that all sound like a good thing, doesn't it?  In recent months, we have seen much of the dark side of complexity.  It seems obvious that more code means more bugs and, back in the 1990s, that was no problem.  Bugs seemed to be just a part of life back then.  It was normal for software to crash.  Today, we know that every bug is a potential security vulnerability and that it's usually simpler to fix the bug than to prove that it's not exploitable.

Not counting browser bugs caused by the over boarding complexity of HTML/CSS, the first larger bug caused by dubious features was Heartbleed.  A feature which may be useful in certain situations was badly defined and implemented.  A rarely used feature in bash caused widespread mayhem.  Recently, strings had a bug in its ELF file handling, a feature which nobody knew was in there.  An exploit may already have been found when you read this.

Bugs are not the only problem that come with complex code.  Perhaps the far bigger one is what I'd call the TL;DR problem.

Shorter texts are easier to read and understand than longer ones.  That's why advertisements usually try to get their point across in as few words as possible.  With code, it means that participating in large projects is much harder.  Also, people will be scared away by the complexity.

Alan Kay once said in his talk "Doing With Images Makes Symbols" that novices can understand up to about two pages of code.  If your project, or a part of your project, will be that small, it won't be intimidating and many more people will be able to understand it.  There are actually such projects out there in real life.

Fuzix, for example, has a version of cat which is just 102 lines long.  Imagine how motivating it can be to show a learner that they can actually understand vital real life code.

Relying on big development teams also poses risks.  What if those teams suddenly oppose your views?  One example is Firefox.

Ads in the browser is something they have thought about before.  Sure you could make a fork, but the need to maintain that huge code base means that you will never be able to deviate much.  GNOME already went into directions people didn't like.  Luckily, they were able to just use the previous version.  With a browser, this is harder as it needs to comply to current standards to be useful.

Small code can be maintained by many more people, and everybody can potentially have their own version of that code running on their own systems.  Why is this important?  More and more, computers influence our daily lives.  They make decisions for us and about us.  The people and organizations that control the code can control those decisions.

In recent months, we have seen companies allowing themselves more and more rights.  Mobile phone manufacturers now regularly track your location even though they have no actual need for it.  Some cloud services want to mine your email for advertisements and even use your photographs in ads.

Code is law, and unlike normal laws where we have to find some sort of consensus, every one of us can have their own world.  Everyone can afford a computer in principle.  It may not be the latest and greatest, but it will be able to run your code.  In a way, this is a great example of direct democracy.

It becomes more and more important that people get the right to not just have an opinion about code, but also to decide, freely and competently, what code they want to run on their systems.

With small and simple code, we do have a chance to reach such a goal.  If people have a chance to understand what their computers are doing, at least some of them will try to understand that, particularly if we make it easy for them.  Of course, we also need public forums to discuss code, just like today we discuss laws.

This would be a job for mass media.  Just think about it - instead of discussing variations of processors and graphics cards, they could discuss code patches: "Ten Patches to Supercharge Your System" or "Does Patch #32532 Hide An Evil Secret?"

Now, how can we make people get more involved in the coding process?

One way would be to change the distribution of software to source code and the distribution of updates to code patches.  This would be wrapped in a nice interface like the ones we are already used to.  To the layperson, this would look the same, except for the automatic compilation taking a bit of time and, crucially, an extra button labeled "show differences."

This button would enable you to view and choose any patches you want.  If you don't want a patch, you can choose to not have it in your system.  This would also be a great way to introduce people to that code, as small parts of code along with a description of what they do could potentially even be understood by a novice.

How do we make code smaller and easier to read?

The UNIX philosophy is one answer.  It tries to promote small tools, each one with simple text-based interfaces and essentially as little code as you can get away with.  This is a logical consequence of the tools people had back then.

Just like an artist will create a different picture when using a pencil or a brush, the tools we use shape the way we think.  In the case of early UNIX development, this was mostly a teletype with a text editor like ed.

You wrote your programs in C or assembler.  Since there was no protected memory, every wrong memory access could crash the whole system.  Since you didn't have a "glass terminal" (a terminal with a CRT which could display literally one to two dozen lines), you had to keep track of what you were doing.

While today, a sign of good code is that every function fits onto the screen, early editors only printed the lines you wanted on request... and that was a good thing as every printed character was accompanied with the loud noise of your teletype.

So naturally, code had to be small, and you thought about how to design even simple tools like "echo" or "cat."

Another answer might come from virtualization.

With that, you can have simpler single purpose systems, lacking everything you don't need.  You compile your system, which may consist of a web server including the TCP/IP stack and some web application into a single binary, then you start it up in a virtual environment which will take care of the hardware accesses.

Suddenly, you have a system which does not need a shell or even a file system.  The attack surface becomes minimal, and even if it does crash, it would be rebooted in milliseconds.  One of those systems is Mirage OS.  There has been talk about it at 31C3 (Chaos Communication Congress 2014): "Trustworthy Secure Modular Operating System Engineering."  It's a single purpose system built of a single purpose.

I believe that now is the right time to stop the trend for bigger and bigger systems and make computing simple again.