Changing realities drives complexity, and the more chaotic those changes, the quicker the complexities pile up.

If you look closely at the pyramids, you can see that the later ones were much more solidly built than the former, having learned from past mistakes. But the reality around them hadn't changed (and still hasn't after thousands of years), so every iteration became more and more efficient since they were building anew each time.

Not so with software! Every time you iterate to make something more efficient, every time you're forced to react to a changed reality or imprecise model or failed assumption, it still has to fit into the overall system and keep working somehow. And that could mean working with a system that has a fundamental assumption that doesn't even hold true anymore, and would require so much work to fix the assumption that it's not worth the cost to fix.

The main benefit of software systems is that they can be reprogrammed to deal with changing reality. The downside is that these systems operate on entropy. That's the trade-off.

We like to scoff at old, "crusty" systems and the morons who didn't know what they were doing, but this is the fate of all software. The difference comes from your stewardship over the project, minimizing the impact of the entropy that constantly assaults what you've built. The Linux kernel is a good example.

It's boring common sense but don't take a bromeliad into the desert.

My belief is that all codebases that live long enough will develop this level of complexity with time. The only exceptions imo are where the codebase solves a very particular, fixed problem, e.g. a library for A* pathfinding or whatever. But maybe not even then.

But there is an awful lot of complexity in otherwise simple things. Just look at hand tools and see the difference between a power drill and a power driver. And realize that asking which one is simpler is a bit of a red herring. Even better, try and guess which one was created first.

I think, often times, people mistake the results of something from the tools that went into it. Such that it can be tempting to think that simple looking creations were made with simple tools. As often, the opposite is the case. It takes complicated tools to build something that looks simple.

Maybe the argument was that you put more effort and work into what you are building than you do that which you use to build it? I think that is largely fair.

That is actually somewhat in focus when discussing a pen versus the "penzilla." For one, building a pen is a surprisingly difficult thing to do. Especially at scale. For two, people rarely want to have a pen for the sake of owning a pen. Instead, you want to write something.

Yeah, except that a sprinkle becomes a dusting, and then a dusting becomes a coating, and then a coating becomes a clog of dust bunnies, and it's often hard to tell when you need to stop and do it a better way when the business side is pressuring you with deadlines for changes on "what already works".

The whole reason frameworks exist is to _reduce_ the mental backpack by using something that has solved the same problems in the same orderly way.

> Software has a Peter Principle. If a piece of code is comprehensible, someone will extend it, so they can apply it to their own problem. If it’s incomprehensible, they’ll write their own code instead. Code tends to be extended to its level of incomprehensibility.

For dim people, like myself. What was the "clear purpose" for Egypt to build giant stone pyramids? Maybe the rest of this will fall into place for me when I understand that.

1. We add more functionality to the base of what exists (e.g. HTML). More and more individual features. (e.g. selecting things in the DOM, animations, effects, interactions, tracking state)

2. At some point someone takes all the patterns in the latest wave of functionality and writes a library for them. Library is widely lauded or adopted (see jquery, React).

3. We think of new features building on top what is now the new norm, it's now table stakes. Rinse and repeat.

This is a common pattern in engineering, for example writing new entries to a DB, then at some point going back and compacting.

For any topic, you might find a perspective that makes it simple.

But then: For a given topic, a lot of parties each bring their own set of simple requirements.

The patterns emerging as the interferences of these requirements might not be simple.

Is it simple though? From my experience, apps written with "sprinkles" tend to become very complex very quickly. Unless the author means something else by "complexity".

Imagine reusing an entire physical assembly for only one of its functions (eg a microwave to get a clock) this is the sort of thing we do in software all the time, but would immediately fall apart in other disciplines.

Of course biologically evolved systems don't occur unless there's some fitness function they satisfy. Well, complex software also provides desired functionality--sometimes the desire is just a result of marketing, but often it's due to real needs.

Right now, "simple" is meant to translate as "good" for the reader and whatever writer wants it to mean. I'm glad, at least, that the article provides an example (React vs plain Javascript). I don't know for sure but I suspect there are at least some valid arguments for using React vs just grabbing dom elements in Javascript.

There are hundreds of boutique brands and almost none are making any money. No one sensibly pays msrp you can find bikes 60% off easily.

When you think about productivity , in terms of how much utility can be produced by one person, it’s obviously declining . We have more tools, but the bulk of the effort has gone into getting attention rather than providing utility . Even the product development is more about marketing than utility

Complexity adds tension.

Bored Software developers add complexity to make their jobs more interesting is my take.

Some complexity in that case is needed, but its aim is to provide a cleaner/simpler access, which is often opinionated, limited to the purpose we have: deployment of development tools for containers.

If you want to experiment, show off as the article implies, start a hobby project.

Edit: removed some fat-fingered typos when I wrote this on a phone

https://en.wikipedia.org/wiki/The_Mythical_Man-Month

Or if you wan to have more fun read Systemantics

https://en.wikipedia.org/wiki/Systemantics

Many businesses are built in such a way that you have little hope of directly contacting your customer, but that doesn't mean you can't try. The desire for complexity often disappears like magic when a developer gets to experience a client expressing happiness over the end results of their "clunky" tech stack.

There are many software products which solve extremely simple problems in very complex ways, sometimes this is called "overengineered". It is what happens, when the simple solution was too boring or when there was a shiny technological hammer and suddenly every problem looked like a nail (think of blockchain products where a simple relational database would have done the trick). This problem exists in hardware as well, but to a much lesser degree, because in hardware every tiny bit you add is cost added to the bill of materials, so hardware engineers have more incentives to keep simple solutions in mind.

To some engineers, them being the only person thar understands the code is a feature, not a bug. That either means they tricked themselves by making the problem appear harder to solve than would be the case (for the own ego), or they tricked others into a co-dependency where the engineer is now needed to understand the solution (for job safety).

One has to admit tho, that some problems are just inherently complex themselves and you have to tackle them at their own level. For example identity managment systems with people from potentially multiple sources where the data shape and quality is out of your control and you still need to reliably create one identity from the data sources. This is a classical: "How hard could it be?"-problem (turns out: very). The solution to that will be complex, because the problems you encounter are. The solution will need to be adaptable because new problems and needs will arise. The solution needs to be maintainable for the same reason. Complex problems + complex requirements = increased complexity in the solution

True mastery in software engineering means the complexity of the solution meets the complexity of the problem, while delivering in all kind of other dimensions like maintainability, legibility, adaptability, security, safety, reliability, ruggedness in changing OS-environments, ease of use, etc.

Many software engineers you will encounter are still in their "write and forget"-stage of their career. They never had to face The Sysamdin that had to deal with their flaming piece of crap software falling apart with every second system update. They have next to no admin experience themselves, that would tell them that good software chugs along for decades in a changing environment.

The problem with complexity in software engineering is that we can just add it. No beancounter breaths down our neck if we add an extra dependency. The problems arising from added complexity are intangible until they aren't, and then it is often too late.

P.S.: I smell chatGPT in some of the phrasing like: "Complexity shouts, “Look at me!”, while simplicity whispers “Did you notice?”."

If there was one reason people gravitate towards complexity this author is talking about, it's probably because they want to see if they can do it. In some contexts it's annoying, but it's also what moves the needle from time to time.

The truth is that simplicity is difficult to implement and even more difficult to maintain. It's easy to oversimplify, as all you need is to not be aware of some complexity. Given that there's infinite depth to things, it's always going to be easier to be missing information than to have enough. But then simplicity is difficult to maintain. Because each time we touch something the same process happens, causing things to compound. If you're 99% "good enough" (a pretty high and unlikely number) then 10 times and you're at 90%[0]. Often a small mistake can lead to big problems. If things run without much slack, then things break. Entropy is a bitch.

The way I think about it is the inverse of how we problem solve. We solve big problems by breaking them down into small problems. Their composition solves the big problem. Consequently, any big problem is composed of many small problems. So I don't understand why we are so dismissive of the little things. The difficulty is figuring out which little problems meaningfully contribute to big problems and which little problems have little impact or are contributing to a different big problem. So when we use dumb thought terminating cliches like "don't let perfection be the enemy of good" we're ignoring the reality of the issue here. If someone believes perfection exists, yes, fix that. But only really junior people think that. Far more often it is a disagreement about what is "good enough" and so the cliche just prevents having a conversation to figure out what that is. No one is omniscient, so why not hash this out?

I think we gravitate to complexity because simplicity is not simple.

[0] This is oversimplified. I'm intending this for communication rather than specifics. Obviously how things compound matters. The numbers are made up but the math isn't. You'll have to read between the lines to determine the complexity that exists for a given situation. I can't be 100% accurate, so let's work together to communicate as best as we can.

Putting a late stage "yea I know, but this one time..." hack in, is logistically simpler.

TL;DR we're not addicted to complexity, we're addicted to the abstraction we started with, even when it turns out not to be as good as we thought.

To convice their managers that only they understand the horrific code they wrote the software in.

Your 1-10 person team probably does not to use the same tech facebook or google are using, most of the time.

I'm not a very clever person, and I keep things pretty simple, so when I explain something to someone, they can generally get a grip on it pretty quickly.

To them it's been such a small jump they think, that person doesn't deserve much of a reward, heck I could have done it.

Whereas when someone talks about the complexity, people think, wow, there's no way that I could have done that, let's pay that person LOTS to keep them

Most of the time, if I'm working in blender for example, I want some really sane prepopulated shader values and one size fits all rig values for sofas vs chairs, but sometimes I want to go crazy and make chairs out of glass and slime, etc.

But simplicity also requieres a lot of effort. Complexity is a side effect of laziness and not putting effort in. Common in corporate programming.

> The simple alternative is just around the corner: sprinkle vanilla JavaScript where it’s needed and don’t build your identity around a framework. That mindset is hard to swallow, though (especially when companies have spent millions convincing developers their stack is the only way forward).

Having grown up doing webdev at its emergence, those were not glorious years.

Even as a solo developer or part of a small team, it was hard as hell to have a perfect mental image of the app at all times, to understand all the combinatorial possibilities of what state your app is in now and what state you want to head to next.

Trying to forever update retained state is hard as hell, full of incredible opportunity for memory leaks, and created some super weird behaviors.

Even more so, "just write the basic code" doesn't scale. It's not a system that an org can follow. Folks will come and go, each going totally different directions. I don't know how to stress how immature and insane this sounds.

But folks love trashing that which is popular. To declare oneself the only sane mind amid a sea of madness.

I really do hope we see some post-React eras dawn, see more, that this isn't it, on and on. But I respect like hell the switch from a retained mode form of webdev to an immediate mode one. It doesn't just skip by so many really bad failure modes, it's often far far faster than the poor incomplete hacked out vanilla.js solution your org ended up with. I want us to change to move to not be stuck here. But to see where we are as unnecessary complexity, to invent fantastic degrading tales about the weak souls of men for getting us here: this is truly the behavior imo of lowlifes, of those spreading propoganda to spread the thinnest false confidence of hatred and disdain against the world.

Things are complex and that's ok. We are learning. The way out in onwards not idolizing a concocted naive pastoralized past.

I know this sounds all very "old man yells at cloud". What can I say. Grug dev only telling fireside stories learned from bitter experience chasing shiny rock.

Job. Security.

You see, if only you knows how it works, how could they get rid of you? /s (obviously /s)