This is why I prefer to liken software to crafting a novel. You come up with a nice self-contained story, a clear story arc with a hero and a villain and a good ending.

Then marketing come along and ask to make it a trilogy and a few weeks before release they ask you to add in Ewoks because it'll sell more toys.

> engineering where constraints are non-negotiable

except that's not really true. The big difference is that to negotiating the constraints when it comes to (physical) engineering, one of the biggest factors is money (and lots of it). "Well, we could double the span but for that you'll need to have parts A1, D5 and T3 built out of ..."

Software development isn't free, but it doesn't typically incur doubling of costs for tweaks to the feature list (and I do mean tweaks).

Maybe the real difference is that costs are hidden in software engineering, but more obvious in other disciplines?

I do a lot of data engineering work, and people are horrified to learn how much costs increase as you go from daily/hourly batch jobs to real time or near real time streaming. Seems like a tweak but it does sometimes incur massive cost increases.

There is an incredibly large space for decisions and belief systems in software that are not evidence-based but that can all lead to programs (in the general sense) that all function and produce the same results while being internally very different.

The _need_ to build higher-level abstractions to manage the complexity or verboseness required to do things from lower level components always seems to be fighting with the _desire_ to build your own higher-level abstractions that fit your own view of how things 'should be', despite many of the decisions going into this being abstract and not easily objectively measurable.

On top of that, software components as 'reusable boxes' only seems to work up to a certain level. The idea seems to be that higher-level abstractions and reusable pieces are all nicely shaped square boxes that all perfectly fit inside other boxes, but the reality seems to be more that even the best reusable boxes aren't perfectly square, have weird edges, and themselves have to fit into larger non-square shapes with weird edges.

And what are the weird sharp edges? Decisions that had to be made about solving a problem. Every higher-level software component is on some level a set of (mostly arbitrary, sometimes measured) decisions about how to take a set of lower level generic components and make something more specific with them. Libraries might assume a certain structure but leave choices for how they're composed to the user. Applications make many more decisions about how their components are used in order to provide a more specific tool. There is a move from genericity to specificity as you move up layers of components.

And finally, software requirements change all the time, but the need to change is itself at odds with the requirement that problems are solved only by making hundreds of decisions that have to work together for a working solution but also may be difficult to undo.

> the constraints and the discipline that it imbues on their craft.

Perhaps the constraints and discipline here comes from a desire to move towards some kind of standard or expected way of structuring software, knowing from experience that the cognitive cost of making (and sometimes having to read and understand) all the arbitrary decisions mentioned above is actually quite high. (This itself also leads to the notion of 'best practices' which seemingly change too often to ever really be considered best).