An example of the building kind: When I bought my house, the first thing we did was knock down the wall separating the front and back living room. We got a cheap estimate, based on the fact that the wall was just a stud wall - it had been knocked through in the past.

Then I got a panicked call from the builders:

Apparently the previous owner (most like, based on some other horrors) had taking out all the brickwork, without putting in a steel joist to hold the hundreds of kilos of brick of the wall on the floor above in place.

The person who had done that work in the first place might very well have seemed very efficient to someone who didn't know the details. To someone who did understood fully what the job entailed, and knew what to look for, once it was out in the open again, the job was obviously not done in a safe manner at all.

But once the stud wall was in place, it was not apparent that there was a problem. First when it was gone and the builders stared up at brick where they expected a steel joist was it obvious the job was violating regulations and was inherently unsafe.

In software, we do the equivalent of leaving hundreds of kilos of brick unsupported all the time, and cover it up with other layers of code, to the point where it is often extremely hard for anyone to determine quality without going back and auditing every line of code and running every little piece through extensive QA.

It might be a failure of management. But often this is because of woefully lacking resources - clients, whether internal or external, often don't understand the importance and refuses to pay for proper management as well as proper testing, qa and documentation. And this is allowed to continue because often it is "good enough" - just like my wall didn't wall down until the new builders had gotten a steel joist in, so often software projects survive horrific decisions or lack of attention to detail.