Of course. The goal is better than nothing, because the consequences of flaws in software are diffuse and not acutely damaging, most of the time. When it comes to things that can malfunction with immediately deadly consequences, then we make it work flawlessly. Just look at the average kitchen appliance -- very likely to malfunction. Your car breaks? Not nearly as much.
It's a shame because human beings tend to ignore the buildup of diffuse consequences until they become horribly acute (climate change).
I'm pretty sure the key difference between the shuttle software and commercial software is just that the latter operates in an environment of much higher uncertainty, and qualitative uncertainty, in that they don't even know the real requirements. This completely invalidates the first principle for the vast majority of cases, since a big up-front design makes no sense unless the requirements are correctly known.
However, principles 2-4 are still interesting and seem pretty valid.
One of the more obscure conclusions you get from liquidity preference theory is that people are willing to pay for reducing uncertainty and gathering information, whereas the time preference framework tends to just assume that everyone is fully informed and is perfectly aware of how what they do today will affect the future.
According to liquidity preference, an year long investment or project with a commitment duration of one month is better than one with a 12 month commitment duration. According to time preference and expected value theory, it doesn't matter, since the future is certain and the time discounted expected value is the same.
Given a 50% failure chance, in the liquidity preference case, the project might get canceled 6 months in, in the time preference case it is assumed that 12 universes pool their resources together and share the returns at the end of the 12 month period, giving every universe a time cost of 6 months.
In the perfect information scenario, there is no benefit in having a liquidity preference theory, they are equivalent. However, what if you don't know the probability of failure? For low probabilities of failure it doesn't matter, but what if you are embarking on a project that is almost certainly going to fail, such as starting a startup? Cutting your losses early becomes extremely important, since you don't have those dozen other universes backing you up.
Liquidity preference has a sort of risk aversion built right into it. People holding money in a checking account are extremely risk averse and have high liquidity preference, hence that money isn't available to be loaned as a certificate of deposit via banks to the startup that is going to fail, the bank will only be giving loans to another megacorp that is acquiring startups with low interest money. Meanwhile according to time preference banks know your probability of going bankrupt, therefore they would just adjust the risk premium, approve the loan and call it a day.
The only investors that are going to give your startup money are those very VCs that want to see "grow or die" hockeystick growth with all the corner cutting on the software side that comes with it and all of this is for a good reason. If people didn't have a sense of urgency, nothing would get done at all! Just take a look at Blue Origin! Their launch got delayed and they missed their launch window for Escapade.
First investor/manager went: so... Ideally it would be 100%, but we all know how the last 20% take 80% of the time, so, how about we ship a pre-release at 80% and see what customers think?
Second manager: ok so those guys did a pre-release full of bugs and they're still around, let's ship our release at 80% also. Pizza for everyone if we ship it before next week.
Third manager: huh. 80%. Bet we can ship it at 79% and re-use those two frameworks which are both half-finished, we'll just offer a free* bugfix upgrade to any customer who complains.
*lightbulb moment: why should it be free if we have to work for it? Let's lock our customers in with a cloud subscription instead, with increasing monthly license fees
I had thought this was going to be about formal methods. Some languages (like SPARK) allow you to formally prove properties of programs -- for example, that they cannot have a run-time exception.
Actually, formal methods would dovetail well with the article's #1 point, "Big Design Up Front": you can't prove anything interesting about the software unless you have a formal spec of what it should do.
It's a shame because human beings tend to ignore the buildup of diffuse consequences until they become horribly acute (climate change).