There have been serious efforts at software engineering, like the OOP movement in the 1980s and 90s to construct software very methodically.

Programmers hate it and rejected it.

To be fair, it does tend to create its own pathology. Instead of a layer cake made of congealed spaghetti, you tend to get over-engineering.

https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...

Software engineering leads to software over-engineering because unlike in physical material engineering there is no capital or material cost to push back against complexity. You can just add things, and add things, and add things, forever, and it costs very little (a bit of RAM and CPU but that's cheap).

I have this weird hypothesis that part of why methodical "correct" software engineering fails is that it succeeds. It is able to manage complexity, which allows complexity to grow without bound. A mountain of ugly shit will start crashing in mysterious ways if it gets too complex, which has the virtue of limiting complexity.

A root problem is that programmers tend to add complexity, not remove it, and the incentive structure of the software business tends to encourage this. Each new bit of complexity or layer is something you could build a business around, or a feature you could sell. Nobody pays for simplicity. It has value, often massive value, but it's not intuitive. In what other domain would you pay more for the absence of something? This would make sense in software since simplicity is harder than complexity, but it feels weird and wrong.