The Pillars of Software

We begin with the premise that building software is hard to do. If you do not agree with the premise, I start doubting that you know have built software before. That does not mean that I am not open to being surprised; after all I consider myself just a middling software builder, surpassed by droves of Jon Gjengset-level principal and staff engineers and technical fellows.

I have been programming for a while: I am approximately the age of the C language, and I was an early starter. My heart was captured by 1Mhz and 64kB of RAM. Within days of transcribing my first BASIC program, I started asking myself the question: “What is the best way to ‘arrange’ this?”. I guess I have never stopped.

So. Why is hardware so hard?

Software is intrinsicly complex⌗

To begin with, software has some very unique “properties”. If we allow ourselves to make a comparison between software engineering and other engineering disciplines, we can establish a bit of a paradigm between software and the “substances” involved in other engineering disciplines: electrons, chemical reactions, structures, dirt and concrete, etc. In that comparison, which we will be exploring further, software comes out as unique in all the aspects we care to look into. In particular, software lends itself to giving rise to astounding degrees of complexity, to the extent that the number one directive when dealing with software is to curtail, corral, ameliorate, and minimize that complexity.

Building software is a human activity⌗

The other aspect of software difficulty stems from, as John Cormack put it, that building software is ultimately a social science, as it is an endeavor that involves teams, communities, and stakeholders. The goal of software builders is ultimately to build things of value, value being a human judgement¹. More pointedly, it requires the interaction between experts at software, and non-experts. In my internal, secret vocabulary I call non-experts “civilians”, and sometimes “normies”.

The author’s position with respect to humanity, people in general, the plebes, etc. is, for the sake of these discussions, one of open misanthropy. When pressed, preferably over a glass of Scotch whisky, this position reveals itself for being first and foremost nuanced, not total, and ultimately held for the purpose of simplifying the arguments.

Should any individual find themselves reflected negatively in these calcas², they should immediately a) feel instantly excused from whatever criticism seems to be being handed them at that time, and b) secretly and humbly admit that there is a morsel of directly applicable censure contained therein.

All of the above is to say, oversimplifying, that people suck, management of technology sucks, programmers suck, etc. and that makes building software way more difficult than it ought to be.

The thing is, there are very good, very reasonable, very humane reasons why people are terrible at software³. Thus, one of the aims pursued herein is to establish a sense of virtue, not in the literal Roman sense of “manliness”, but in the sense of “that to which one should aspire to be”