by sunrunner | 2025-04-06 13:09:41+00:00
> CV building for FAANG type job hunting, job niche building and job security self-indulgence, and a fundamental disregard for maturing the industry

I think there is both an inherent complexity and artificial (or 'introduced') complexity in software.

Inherent complexity comes from increasing expectations over what kinds of software we want to write (the evolution of the web and browser 'features' since its initial inception, the kinds of interaction on mobile, tablet and desktop devices) and _how_ we want to write that.

Some amount of higher-level tooling is almost a necessity because the absolute amount of lower-level things needed to make the more powerful abstractions work is too high to deal with practical. Want to write a cross-platform fully-featured-with-animation UI toolkit with just the raw hardware in your desktop? Fantastic exercise for learning, but you're almost guaranteed to start reaching for higher-level tools at some point in the journey.

The growth in artificial complexity, however, comes from so many places (including all the ones you listed).

Sometimes it's from processes and ways of working that are introduced (I sure hope you do fully automated releasable builds including management of the computers that do those).

Sometimes it's from socio-technical problems (working in a single shared code base and having to coordinate changes and releases? Surely it would be easier for teams to never have to talk to each other and just release small things independently...).

Sometimes it's from an approach to building software that is perceived as better, easier and faster (shipping a desktop application? Wouldn't it be so much easier to just bundle a full UI layout engine, scripting language interpreter, hierarchical appearance control syntax, portable bytecode interpreter and some application code that was itself compiled from a _different_ language so it could be interpreted by the interpreter you actually shipped...)

Sometimes it's from system design approaches that are pushed as 'best practice' and introduced without necessarily understanding whether you ever had the problem they were intended to solve (please, tell me more about how your relatively small ecommerce application needed to be event based in order to 'scale up').

Sometime it's because the handful of companies shipping acceleration hardware have practically zero commercial incentive to standardise on an API for writing programs that can run on said hardware, giving us a world with four (at least) slightly different syntaxes that all sort-of-mostly accomplish the same thing while being awkwardly different.

I could go on...

Not that some of the artifical introduced complexity doesn't sometimes solve actual problems or be an overall-useful thing to have. No criticism here on introducing software-based processes to formalise things, improve software quality, and so on.

But it's useful to keep in mind how much of the complexity is introduced to improve overall processes versus 'solving' for some local maxima by adding more tech without the overall software quality improving, with the end result being we've made our own lives worse in some way, without measurably improving the resulting application.