I used to say you could release stuff often if it wasn't safety- or security-critical. The latter should be reviewed & hit with various scenarios before any rel

I used to say you could release stuff often if it wasn't safety- or security-critical. The latter should be reviewed & hit with various scenarios before any release. The model of non-critical software seems to be purely time-to-market, adding features, sometimes subtracting them as a differentiator, and lock-in. This combo created several multi-billion dollar firms plus lots of other shops raking in the big cash. Minus the lock-in, the model drives the successful projects in FOSS. The bugs can be fixed later with patches which can even be sold to customers. You win then win again. These days I'll add any non-regulated, security-critical product to the list of things to rush simply because most of them are crap. The likes of McAffee and RSA Inc. got to the top with the security "features" w/ correct extra stuff (eg tie-in's to Microsoft stack), sales teams, support, and so on. They didn't do a lot on "assurance" that what they delivered was secure itself or worked despite clever adversaries. So, if you want money or market share, just do exactly what they did. I will add that there's methods for developing software that still move quickly while reducing defects. Particularly, if unreliability might hurt you, follow Cleanroom methodology's take on testing by focusing on usage-driven testing. Come up with as many scenarios as possible representing how users will actually use the product. Make sure all those scenarios pass. That means the defects that slip through are those average user might never see. Obviously, things like memory-safe languages, interface checks, and quality libraries from 3rd parties help, too. This collectively gets you better defect rate than most of industry with hardly any extra work.