There’s a big movement in software development to do rapid release cycles. We tend to release every two weeks. If we ahve major work to do, we can expand the window, and sometimes we have just a small sprint and code, test, and release in a week.

Software, be it a simple website or a complex platform, is never done, it seems. You draw a deadline for a batch of features and release them. The next time around, you fix the bugs the last release introduced that your QA process missed, introduce some new features, and probably slip in a few new bugs.

Why do we do this? Why do we need patches and updates? We bought a fairly high-end toaster a while ago. It’s sat in our kitchen for a few years making toast. (Err, making many pieces of toast on many occasions, not spending several years making one piece of toast.) There have been no updates or patches or service packs. It has zero bugs and no security vulnerabilities.

I started thinking about how you’d write code like that. And my conclusion is that you’d have to stop “rapid iteration.” At some point you have a feature freeze, and then you spend months testing, and fix every single little bug, even the, “The bug might affect 2 users ever, but the fix has the potential to break some core functionality in subtle ways…” ones. You’d spend a lot of time making trivial fixes, and a lot of time testing against unlikely uses.

A big problem we find is that we can easily test functionality, but that the real world does things we would never try. People try to stuff bananas into toasters in some cultures and they jam. People bring the toaster to Europe and plug it into a much higher voltage than expected and it blows up. Some lunatic has his outlets wired for DC, and the toaster short-circuits. When you use the toaster inside a cryogenics freeze locker, it never gets the toast warm enough. Some of these are so ludicrous that they’re not worth fixing, but others are legitimate uses that no one ever considered. And yet, somehow, toaster makers never run into these problems. There’s a pretty well-defined set of conditions in which a toaster should operate, and they’re tested in all of them.

But the big thing with the toaster is that you know that it’s got to just work, because you don’t have the option of pushing out a patch release. If people run into bugs with their toaster, they’re going to return it and use the money to buy something from a competitor. They won’t submit a bug report or wait for a patch.

I don’t think this process is going away, but it’s something I find interesting to think about. If you only had one shot to get it right, how would things be different? Do rapid release cycles just make it too easy to release imperfect code?