You are making the common mistake of confounding essential complexity with accidental complexity. One you are stuck managing and one you can eliminate with skill. The world isn't getting less complex just because you work harder on your software.

Also it’s not about working harder; it’s about building smarter—building simple systems—which absolutely makes your world simpler. ‘Essential complexity’ is what sophomoric developers decry when they are unable to architect well—and are unwilling to do the hard work it takes to learn to architect well.

The world, from software’s perspective at least, isn’t growing in complexity. What leads one to that?

The world growing more complex from the software's perspective.

And by that I mean, it has to account for more scenarios or do additional things... unless your software is growing in complexity while you're only removing features...

Bugs in software come from thinking we're simplifying the world in one way though the program, while in reality it receives a slightly different picture.

A well-built software system doesn't have to grow in complexity over time. More features does not equal more complex in the true sense of Simple.

Faulty data models and system designs -- that aren't fixed -- lead to ever-increasing complexity. But that is the fault of the data model/designer.

I.e., there is a way to build (and grow) systems w/o linear increase in complexity -- but it takes a particular rare skill set.

> The biggest differentiator of skilled software practitioners is the ability to construct simple systems.

I would say it's to construct simple enough systems, and the hallmark of skill is a developer's ability to define enough.

I believe you're conflating simplicity/complexity with flexibility.

_One_ hallmark of developer ability is the discretion/wisdom/experience to know how flexible to make the thing. (How to prioritize and limit feature-creep, etc.)

But this is different than Simplicity. A general purpose programming language or database -- highly flexible/generic systems -- for example, can be built well/simple. But so can highly _specific_ systems.

In both cases though, one can build something that is decoupled and manipulable or one can build something that is coupled and rigid -- and the ability to do so is a function of skill set _not intrinsically_ a function of time. In other words, a skilled developer doesn't have to "take time" to deliver a Simple capability.

Sometimes you just want a hammer, not a swiss army knife.

And sometimes it is good to have a replaceable head on the hammer.

Yes! And the property of Simplicity is orthogonal to whether or not you chose to make the Knife or the Hammer.

A Hammer's construction can be Simple. A Knife's construction can be Simple. Or not.