There's only one answer: exhaustive testing and attention to detail, NASA style. With NASA it's probably worth it. The rest of us, not so much. Like efficax

There's only one answer: exhaustive testing and attention to detail, NASA style. With NASA it's probably worth it. The rest of us, not so much. Like efficax says, there's an oft-used analogy between software "engineering" and structural engineering that I think is way overplayed. The better analogy, IMO, is between software and business. What "CEO" means is basically "authority and responsibility." We have some guardrails called laws, but outside of that we acknowledge that "CEO'ing" is a complex, ambiguous task requiring personal judgment, and is not reducible beyond that. "How careful should we be?" is a question with some interesting characteristics: - it's a matter of opinion. How risk-averse are the shareholders? - it's a matter of context. On the CSS for the company promo site: eh. On the embedded code running the flight-control system---very. But what if that stems from MVP code that originally ran in a simulation on the company promo site? I mean, what you really need here, is for your board members to write the code. I'm speaking tongue-in-cheek a bit, but I'm not sure it's 100% wrong, maybe just 75%. In a very real way, the authority-responsibility-reward lineups are so out of whack in most organizations. Which is not to say I know what they should look like. (Two words I need to think about more: "Software insurance")