Much like a simple physical object, such as a chair, software is essentially just a system designed to solve a problem. But unlike a chair, in modern software the relationship between a problem and its solution has been abstracted away under layers upon layers of complexity. For this reason our understanding of a good, which is to say effective, chair versus effective software has diverged more than it logically should.

Say a chair is broken or wobbling, and we’ve been tasked with fixing it. A chair is a very simple system to understand - it usually only has a couple of elements which are interconnected in obvious ways. It’s also easy to see the problem the chair is solving - one wants to sit down - as well as the relationship between this problem and the chair’s solution: it must provide a flat surface lifted from the floor that is large enough for a person to sit on. It’s easy to understand this goal and to notice when it has been met, and if it hasn’t, to make the object meet it. In a broken chair, for example, the sitting surface may not be flat, so we must make it flat in order to consider the chair fixed.

Since at the most basic level software is just a very, very complicated chair, it would make sense to have very similar fundamental criteria for fixing it, but we sadly don’t. Most times when we say software is ‘fixed’, it just means the program can run, or run efficiently enough. In the chair analogy, however, software that can run is just a chair that can exist - not necessarily a chair you can even sit on, much less a quality chair you can sit on comfortably. In other words: software that runs really well might not solve our given problem, or any important problem whatsoever. It’s like a useless chair, but worse, because it won’t usually be thrown away or turned into something else, but rather resources will be pumped into it to improve parts of it gradually, while keeping it virtually useless at its core. We likely got ourselves into this mess because we just started writing code without having deeply considered how exactly it will solve the problem at hand. Maybe we haven’t even really understood the problem at all.

But that’s only the most extreme example. Even when software does indeed solve our given problem, humans have insisted on giving it other unnecessarily un-chair-like characteristics. For instance, most software has a lot more movable parts than it needs to have, and they are often woven together in nonlinear ways, which is why fixing one part can sometimes break another. Also unlike a chair, most software is not designed so that parts fit together in a more or less self-explanatory way, or even in a way that is reasonably easy to explain. Last but not least, you could theoretically have a chair that works perfectly, but does so with way more parts than needed, for instance it could have 8 legs. But that never happens in the chair world, because the ridiculousness of this is intuitively apparent to everyone involved in the design and production of a chair. Unlike the software world.

Historically, the role of software consultants was usually to have some sort of specialised knowledge of a part of software, say on special kinds of bolts in our chair analogy - something the average engineer wasn’t an expert on. But that was before the problem of overly complex (or un-chair-like, if you will) software has become an industry-wide one, and before the ultimate democratisation of knowledge via ChatGPT has taken place. While specialised knowledge is still undoubtedly great to have, it does not in and of itself help with software complexity. Even worse, in some instances, for example when people with specialised knowledge are improperly managed, it can be used to make matters worse - for example to make a part of system so intricate that it no longer properly serves its function in the system. Again, if this were a chair, this could mean shaping its leg in the shape of a beautiful horse, which, while certainly exciting, will at some point cause the chair to wobble. In the case of the chair it will be obvious to any reasonable person this is a bad idea, while with software the manager of the chair leg project will congratulate themselves on the beauty and intricacy of the utterly ridiculous horse-leg, while declaring the subsequent wobbling of the entire chair a feature, not a bug.

What software consultants of the future will have to do is essentially just call bullshit on this. This doesn’t need to be a requirement for the average engineer, but the industry will need at least some people who are able to see software as a chair and have the guts to speak out on the parts which are neither legs nor seats, uncomfortable as it may be, to prevent software complexity from growing infinitely. ChatGPT can’t help us much in this department, which is also why its mindless use can do more harm than good. Software complexity is fundamentally a product of human biases, thus only humans can counteract it. Seeing software as a chair means looking at software purely from a standpoint of a relationship between a problem and its solution, and it’s a skill and a practice that grows more important proportionally to complexity itself.