2 ms·

I think you have hit the nail on the head, focusing on the wrong things. The problem is that software engineering is still, in many ways, in a pre-scientific e

• godelski 2y ago
  > For example, civil engineers know how to build bridges that are good enough, i.e. that barely stand. And "good enough" is a relative and changing thing. What was "good enough" thousands of years ago is nowhere near standards today. This is even true a hundred or 50 years ago with the specific example of bridges. Engineers learn this the hard way because the results are visibly catastrophic and usually through the loss of many lives. But I think one of the difficulties of software is that failures are often less apparent and can be difficult to accurately attribute. But then again, when a bridge fails there are both internal and independent investigations that are extremely thorough and result in updated policies. This does not seem to be the same in software (at least to nearly the same degree), in part due to the abstracted nature of how software can cause harm. It is actually harder to attribute error (like you said, formal methods exist, but are costly and not just in the monetary sense).