The problem with most software isn't that it can't be modelling and rely on basic physical principles, it's that many projects fail to take specs and testing seriously
Most requesters (users) don't really know what they want UNTIL they actually see something concrete, and then realize it didn't fit what they had in mind. We don't need engineering, we need mind-readers. If users had enough time to sit and be thoroughly interviewed about needs and preferences, they wouldn't need automation to begin with.
And further, how to make software maintainable in the longer run is highly disputed largely because it depends on "wetware" and unknowns, such as developer perception of code, and unknowable future domain changes.
It's more akin to writing technical documentation than to building a bridge: how do you write documentation that's clear to the audience, but flexible enough that it doesn't have to be largely reworked for every change.
There is no magic modularity formula: domain issues inherently intertwine (or can intertwine in the future even if not at original launch.) You can't hide intertwining, you have to find a way to manage it well.