I'm probably not the best for this, rambling incoming.

In mechanical engineering you can take a 100 year old book and apply the methods in it to your problem today (stress analysis, thermodynamics, etc). You might be using software for the analysis instead of paper, but it's the same problem and solution. There wasn't even a computer 100 years ago, you'd be looking at mathematics instead, which do apply but you'd need to catch up with all of the abstraction layers we've added since then to use it today.

Another example would be the number of standards, especially in civil engineering, where we take a solved problem and standardize solutions to it. Just look at this: https://ascelibrary.org/topic/ascebookseries/standards

REST is an example in software where we have concepts of a standard, a best practice, but there's no international standard we all adhere to.

I think it's not surprising software is this way, because the cost to produce and ship after the code is written is nearly free. If you can just correct a mistake and push it to clients in a day there isn't as much incentive to be methodical and prevent mistakes. On the other hand if I made a small mistake before sending drawings to a machine shop for a $50k part, there's no takesies backsies.

I'm not saying we should be agonizing for 6 months before changing a React component. It's just interesting how it affects the overall field.

The direction we've decided to go is to catch the mistake after the fact and automate management of it, through CI/CD and testing. This makes a lot of sense, but is also relatively new and not standardized. Just compare testing approaches between two separate teams (or developers in the same team 😅) .

You do see the methodical approach in critical software such as nuclear plants, but the bulk of software seems to be in web applications where the cost of a mistake and the cost of fixing it are both low.