Usually software is easier to take apart and modify than other engineering products, so it doesn’t make sense to hold it to the same standard of correctness, and prioritize speed of deployment more.
>Usually software is easier to take apart and modify than other engineering products,
I do not think that is true. The one thing software allows is a large degree of modularity. In Electrical or mechanical engineering everything can always influence everything else. In software you can have very strong boundaries.
>so it doesn’t make sense to hold it to the same standard of correctness, and prioritize speed of deployment more.
I think this is debatable, but I understand where you’re coming from.
Personally I think it would be a better world if software were held to the same standards as other engineering disciplines, and we didn’t treat it as somehow less important for software to be correct just because it’s easy to fix. Things would move slower, but we wouldn’t be “spinning our wheels” nearly as much by redoing work and reinventing wheels over and over. A world where software can be considered “done” when it works and is free of bugs sounds amazing to me.
I see so many mechanical bugs in my farm equipment, I have to question your notion that other engineering disciplines are actually held to a higher standard.
Similarly if the software causes a worldwide outage of critical infrastructure.
In many cases it is imperative that the software be correct from day 0. Just like a bridge.