Part of the reason this becomes so dangerous is myopia. If I'm "just building an internal issue tracker", sure, I don't need to spend ages securing it . . . unt

Part of the reason this becomes so dangerous is myopia. If I'm "just building an internal issue tracker", sure, I don't need to spend ages securing it . . . until someone else exposes it to the open internet because that's the only way to make it available to offshore partners (which in turn is because someone in networking made the--from their perspective reasonable--decision not to pay for the setup of a VPN because it was expensive). Each person is making more or less reasonable decisions, but the way they interact with the rest of the whole is what causes disasters and inflicts real harm on people's lives. A question I'm interested in is: "real" engineering has the same issue of scale and potential myopia. Consider the guy mixing concrete at the batch plant on a tight schedule who, faced with an impending shortage of aggregate, mixes a little less into his mud--he does this so the trucks lining up to fill won't have to wait for the other truck bringing more aggregate. Now, his concrete was headed for a bridge, which is genuinely structurally compromised by the lack of aggregate. Do things like this happen in other fields of engineering with anywhere near the same frequency they happen in software? Why or why not? (In the concrete example--and, to be honest, this is just 'cause I like talking about concrete--there is no "right" answer given the shortage. "Fatten" the mud by lacking aggregate? Structural issues. Let trucks wait? Jobs with unfinished pours may have premature cementing, which, unless their contractors are willing to bite the "tear down the partial pour; it's too cemented--wreck it, rebuild the forms, start over" bullet which pretty much always ends up pointed at them and not the batch plant, leads to . . . you guessed it, structural issues).