Alphas, Betas and Why we’re all Guilty

It’s been remarked upon of late that the concept of beta software has changed dramatically over the last ten years. Perhaps Google was a major influence (sigh… Gmail) or perhaps the Internet in general.

The terms ‘alpha’ and ‘beta’ have become muddied and confused over the years. Here is what these initial releases once meant:

Alpha Builds: Alpha releases where (and still are) largely internal builds used for evaluating the code. This stage of the product includes UI re-design, features being dropped in and out and lots of bug-fixing. Traditionally by the end of this stage the product would be code complete and usable.

Beta Releases: Either ‘closed’ or ‘open’. Beta builds were nearly feature complete and should be stable enough to be used. The point of a beta release wasn’t to discover any bugs in the software, but to discover bugs which the developers hadn’t yet discovered themselves through internal testing. Some of these are obscure and need wider testing.

Release Candidates: We see these less frequently these days, but a RC release is code complete. No new features will be introduced and all that’s left to do is find and fix the last few remaining bugs.

What these mean today:

These days I have no idea how exactly the development cycle works. Most developers seem to want to get usable software into users hands as soon as possible which is both good and bad.

ZDNet described this back in 2005 as:

Beta tests are getting longer, less restricted and more common, as companies tinker endlessly with their products in public.

The good is that many more bugs are picked up during the development cycle, user feedback can contribute to the project and it gives the software greater publicity then if they only tested internally.

The bad is that beta software can give a company or service a permanently muddied name. People expect beta software to be usable both performance and feature wise and anything which isn’t gets slammed. I have been guilty of this myself in the past.

When it comes to reviewing pre-release software, performance and stability should never be included as part of the review. Instead the focus should be on the possibility and promise of what the software is aiming to do.

I’ll try to remember this myself as I write and review products.

Advertisement