April 20, 2014

Complexity Is Irreversible

Once again, programming language flame wars are erupting over the internet. This latest one gives us a helpful list of "harmful things" and "less harmful things". Unfortunately, I felt that it was a little inaccurate, so I decided to improve it:

Harmful things

Less Harmful Things

Things That Exist

Things That Don't Exist

Just to clear up any confusion, here is a helpful diagram:

As many very smart people have pointed out over the years, the ultimate enemy of software development is complexity. Unfortunately, you can't get rid of complexity if the thing you are making is inherently dependent on something complicated. I think most people will agree that real life is a pretty complicated place, and the human brain is an awfully complex irrational thing that is trying to interact with real life.

This can't end well, and it doesn't. When we try to do anything, we wind up with something complicated. This isn't because all problems are complicated. The issue here is that in order to push a button on your calculator application, you have to go through a UI thread to the software through 10 different functions each calling into the operating system which is on top of the kernel which is on top of the microkernel which is on top of the BIOS which is on top of the motherboard which is controlling the CPU which is built using microcode which is executed using a bunch of extremely tiny logic gates on a chip.

Now, we could build a computer whose entire purpose is to let us push a button on our calculator application, and it would be much simpler! All we would need is a button command built into the motherboard to a RISC CPU that operates a few logic gates on a chip. This mysterious object is called a calculator. You know, the real, physical calculators that nobody uses anymore.

The reason we don't use them anymore is that we need our computer to do a lot more than simply be a calculator. This is why everything is so complex - if you want something that does several different simple tasks, you will end up with something complicated, even if the tasks are themselves simple. We can, of course, still pretend that everything is simple, just as the OS abstracts away all the low-level nonsense required to make your computer work properly, like setting that goddamn A20 gate on the CPU every time it boots. However, simply pretending something doesn't exist does not make it go away, which is why that stupid A20 gate still causes mysterious boot errors. Hence, any simple program written in any language imaginable is still subject to mysterious bugs and memory leaks that don't make any sense because they are caused by the inherent complexity of the system they are built on top of. You can't un-complicate something. Complexity is irreversible.

Nothing you do will fix this. If you use C to try and keep everything simple, you'll destroy the entire internet's secure infrastructure because of a completely retarded mistake involving an asinine and ultimately useless memory allocator. But if you use a managed language, before long you're writing a UI in XAML and suddenly you're looking at a call stack the size of Mount Everest.

Despite this, there is no end to the deluge of misdirected attempts at "solving" or "reducing" complexity, despite the impossibility of the task. What happens is that a programmer makes a bunch of mistakes, and notices a pattern. Because they're a programmer, they immediately invent a language that prevents them from making those mistakes, and then claim it's the solution to all the world's problems, while conveniently forgetting that the rest of the world has completely different problems.

But, I digress. My point is that the only way to write a piece of software that doesn't break is to hire someone who's so incredibly smart they can deal with all this complexity.

2 comments:

I really like what you say about complexity. One of the things my employer does is build software that enforces contracts between cities/counties/regional governments and ambulance companies. You would think that the contract would be insanely long (they are), detailed (yep!), and handle just about every contingency (oops). The problem is hard enough that my company has about 3 fulltime employees working on it all the time and every single new customer is a new set of difficulties. We often end up digging out the "obvious" details that never got written down.

For extra irony, we've tried to standardize the process. It's working out pretty well except...some customers need to so many bits of data to determine if you get a big fine or not that we run out of fields in our existing database tables.