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).
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'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.
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.
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).
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'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.
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.
I wonder what the price tag is, and how expensive is change.