The Web, and particularly anything self-consciously Web 2.0, is fraught with examples of perpetual public Beta status. Gmail has been in public Beta for years now. Few enough people knew what Beta meant in the development process before all this started: fewer still are sure they know what it means now, at least as it applies to web applications. Previously, the idea of an application of any sort being in a Beta testing phase for a period measured in years would have been regarded as patently ridiculous, but now it seems normal. It almost seems a badge of honor.
What a line of crap. Beta doesn’t mean you’ve “arrived”: it just means you’re afraid of finishing what you started. I have a point to make here, and I’ll start by explaining how the software development process works, traditionally.
The standard development release cycle for software goes through some distinct stages.
- Pre-Alpha: This is (formally speaking) when the project is in initial development, and the core architecture of the system is being pieced together.
- Alpha: This is when the project has reached a point where there is a working system, and major features are being incorporated. The point at this time is to get the project to a stage where it resembles the final functionality users should be able to expect from the software.
- Beta: This is when the software mostly has its final form, and is being actively debugged and having the kinks ironed out. As indicated in Beta–the four-letter word of Web 2.0, perpetual Beta status can become an excuse for chronic bugginess, since working on bugs is really the point of Beta status in formal terms.
- Release Candidate: This is also known as Gamma status, where you have something that you feel is debugged enough for release but wish to put the software through final testing to ensure that hordes of irate customers will not come burn your house down when their mission-critical data is eaten by the software.
- Release: Also known as Gold, this is where software is finally (theoretically) “perfect” and ready for general consumption. It is retail-ready, in other words, available to the general public using whatever business model the developer intends to be the main means of acquisition for the software. It’s “done”.
On the Web, things happen a bit differently. A lot of this so-called “Beta” software is actually essentially in its final release form — except that there is no static release form, because iterative development continues. It’s simply understood that the web application is considered “stable” in terms of functionality, relatively bugless, and usable for serious, business-critical purposes (where appropriate). It’s definitely post-Beta, but it also doesn’t strictly fit the definitions of Gamma or Gold (Release Candidate or Release), because it will never be “frozen” at a particular state of usability unless its developers simply abandon the project.
Alpha, Beta, and Gamma are the first three letters of the Greek alphabet, and have been assigned to the three primary stages of pre-release development that feature a working system in that order because of that natural progression. In terms of the common case of web applications, it seems to me that there’s a fourth letter, in finished-ness somewhere between Gamma and Gold, that is the actual “final state” of the software project, and as such we should use the fourth letter of the Greek alphabet: Delta.
Because there’s no Gold, or Release, version of the software in the sense used for traditional, commercial desktop application development, there’s no Release Candidate version in most cases either. As such, the development process for web applications should progress through Pre-Alpha, Alpha, Beta, and finally to Delta. Let’s aim to get our web applications out of Beta and into Delta release status. If we think of it in these terms, we shouldn’t have the same hang-ups about moving out of Beta as we would if we were to attempt to fit web application development into the traditional, commercial desktop application development box.
The term Delta is particularly fitting, considering it is also used in engineering practices to refer to change. For instance, “delta-vee” refers to a change in velocity. Similarly, Delta status for your web application would mean it is in an ever-changing, dynamic (but stable) release state.
Language can help us think about the subject of our words more clearly. Let’s use it to that end. Get your web application software out of Beta, and into Delta, this year.