Software is its own worst enemy. As a Software Engineer I dislike software; I try to write as little of it as possible. When software inside the system has become obsolete, it will be removed. If the software doesn’t serve a purpose it only adds negative value. Some of the best sprints I had were ones where I ended up with a negative amount of lines of code produced.

This is incredibly counter-intuitive to almost anyone who’s not an experienced software engineer. Can you imagine being paid as a recipe writer to just remove recipes? It doesn’t make much sense for a recipe writer; but for us it definitely does.

A great example of how complexity is harmful is in the Minecraft video. Around 14:50 the author is explaining how he uses coloured wool blocks to encode data (for example whether a move is a 'Fire' or 'Water' move). When talking about a second layer of these blocks he mentions that he doesn’t quite remember exactly what these blocks do anymore.

So imagine this. This guy is a brilliant programmer who wrote all this stuff by himself. It’s not code someone else wrote. The 'code' is right there in front of him. He’s not a junior developer either, he designed the entire system by himself. But he doesn’t know what it does; he’s just guessing it!

We humans are incapable of handling this level of complexity. This is why we need to build abstractions of this complexity, without it we can’t even reason about it. Or to quote Dijkstra:

The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise — Edsger W. Dijkstra

Our puny brains can’t fit all this information. If there are things you haven’t used for a while, like what those blocks are used for, our brain tosses it out. This is why we put lines of code into functions, functions into components, components into modules, modules into systems, systems into architectures. We need higher and higher levels of abstraction to even be able to reason about the complexity of these bits of code we deal with on a day-to-day basis.

In the video you see that the developer did this too. The blocks are stacked into columns and rows that make up functions. Similar functions are grouped together into modules. And these modules are then grouped together into overall systems (animation, input and game rules). This is not code that randomly grew; he did up-front design.