Beta
Alpha, Beta, Gamma, Delta... what is a beta version anyways? It's a late development release, but pre-final.
~ Aristotle Sabouni
Created: 2003-11-05 |
It's all Greek to me[edit | edit source]
Beta comes from the second letter of the Greek Alphabet.
| For those who care, the Greek Alphabet goes; alpha, beta, gamma, delta, epsilon, zeta, eta, theta, iota, kappa, lamda, mu, nu, xi, omnicron, pi, rho, sigma, tau, upsilon, phi, chi, psi, omega. |
The way "Beta" originated as a software term was that alpha software was the first versions, and beta was the second round of tests. In order to better communicate and manage expectations, there was some standardization of the term meanings that we are supposed to have and use today.
- Development versions : internal-only software, not meant to be seen by users or people without NDA's (Non-Disclosure Agreements). This software is very buggy, not-near feature complete, and usually has debug code all over it, and weird pseudo-features that only a nerd could know and love. More a working test bed for where things are going.
- Alpha versions : first versions you'll show. (Still, usually only to people with NDA's). These are non-feature complete versions of software; they are missing core functions and usually are littered with test code and holes, but starting to go through QA (Quality Assurance) for testing or even some Usability Testing on features. (For companies that do either of those). Usually buggy, with possible catastrophic bugs; so usually demoable, but not reliable or very usable.
- Beta versions : these are the first feature complete versions, that are pretty stable and usable. Since testing has been going on since at least alpha, most of the major bugs should be worked out, and every feature that's going to ship (barring some last minute re-work) should be in there.
- Golden Master (GM) / Final Candidate (FC) : this is the last version to be tested before shipping - barring any catastrophic last minute bug discoveries. The "Golden Master" is actually the master disc that will be pressed into commercial software. But sometimes there are last minute (or last second) discoveries in testing that result in more than one final candidates. More often than not, it just ships and then there's a quick .01 release that fixes the bugs found at the last minute or by customers when you ship and your testing base gets much larger.
De-standardizing[edit | edit source]
Now engineers invented and use these terms. The problem is that marketing and management often don't care about the substance as much as the symbolism, and seldom care what engineers have to say. So management and marketing use them differently, and laypeople are even worse.
Management wants to look good and like they are progressing, and development starts slowing down the later in the project it gets. The easy bugs and features are added or fixed first (known as going after low-hanging fruit), that leaves the nasty stuff for the end (and the slowdown begins). Also the complexity of the solution is going up over time (meaning it takes more time to find and fix things), and the amount of time doing support or bug hunting, versus new feature development is changing as well; thus less "new stuff" is getting done. And then management likes to have more and more meetings to figure out why it is the natural order for things to take longer near the end. Many things conspire to make progress slower.
Since companies usually pre-announced the project, they're getting tons of questions like "when can we see it" or "when will it ship". So management pushes for things to be "beta" long before it is ready, because it sounds good.
Laypeople have learned that beta means, "it will be shipping soon" - so management wants things to be "beta", ready or not, because that will appease the huddled masses of customers knocking on their door. The results are that now the terms are all messed up because Beta may really mean, "developmental version that we're showing or giving to customers in order to shut them up".
Now whether beta is "feature complete" or not is disputed. Most companies that value quality require betas to be feature complete. The reason is because any new feature can destabilize the software and introduce bugs that drop reliability back below Alpha. No one who values quality can drop in a new feature without regression testing (testing all the old features as well as the new), because there are hugely complex interactions in software that can stop you faster than driving into a brick wall. Now many don't do that level of testing, and will only occasionally get bit. But when you do, you get bit hard. These companies also tend to call things beta before they are feature complete, and in so doing they prove that they do not value quality.
| While beta test agreements say things like, "may eat your homework, destroy your hard drive, and take the lives of your first born", it isn't really supposed to mean it. That's just the legal mumbo-jumbo used to cover ones butt. In all reality, if you have any catastrophic bugs that are destroying files or injuring innocent passers-by, then you really aren't yet out of the Alpha or even beyond the developmental stages, no matter what management and marketing is calling it. |
While the term Beta is supposed to mean "feature complete, on the final bug-hunt, and damn near ready to ship", Microsoft and others have made the term creep to mean, "what we're done with so far and willing to show at this time". Which means it could be one month to as long as a few years from actually shipping. The longer it takes to get from the start of beta to final shipping, then the bigger an indicator that is that the company doesn't know what the terms mean - which is a flag on their quality. However, the larger the system and more complex, then the longer it usually takes as well. But you'll really know how much they value quality by how many bugs are left in when it finally ships.
So the problem is that there has been major entropy of the terms, and a huge devaluation in quality. It now takes much longer to get from first beta to final shipping, because first beta really means alpha. And worse, some companies just ship betas to customers and call it a "release" to let them test it out.
Insights[edit | edit source]
If a company ships you "beta's" that are not feature complete, then they are not an engineering centric company that values quality; they are a marketing driven company that is willing to take risks (that you will crash and burn) in order to buy themselves a little more time.
I do value seeding programs and getting software sooner for evaluation. Calling alpha seeding part of their "beta program" says that either they don't have the experience and expertise to know what the terms mean (which is dangerous), or they know and do not care (which is worse). If companies put me in their development seeds, or alpha seeds, and call them such, then they are letting me see it sooner, and not trying to mislead me.
Even worse are the companies that continually ship software that has many bugs that would have been caught in any normal "beta" program, had the cycle been long enough, and the seeding wide enough. If companies have to continually release .01 releases to fix things (especially obvious and serious bugs or omissions), or if they keep shipping things that are missing major features, or have no polish to the features they do have, then what they've really done is rename the alpha as the beta program, and are now using me as their unwitting beta testers. They are yelling to me that they don't value quality, or me as a customer. I think they should get a bill for each bug I find, or each piece of data I lose (or things I have to do over).
| One or two mistakes is good faith; they tried to fix it. Software is complex and there's always going to be a few bugs that creep in. Repeatedly shipping with many known bugs, especially ones that can destroy data, or not putting enough time and effort into testing, major missing features, or features that don't work right, is outright fraud. It is like the difference between a doctor having an honest mistake and nicking an artery, or the quack who doesn't know what he's doing and is operating drunk. Microsoft used to be the perfect example of a bad company on this end; have huge beta-cycles with radically changes in features along the way, and still shipping unreliable garbage. But they have been getting a little better. Apple used to be a great example of a good company; short beta cycles and being feature complete, with most 1.0 software being thoroughly tested and usable from the get-go. Sadly, Apple has become far more pragmatic, so while I still think Apple is better than Microsoft, but they've been following the industry trends downward; saving testing time and money, and getting the obvious quality results. |
Conclusion[edit | edit source]
You can learn a lot by how companies use the terms. See what the terms mean to that company, and it will give you insight into how the company values you as customer or values their own quality and reputations.
When a company does burns customers, I learn to avoid major problems on my machine by waiting until the other pigeons are the early adopters (or late testers), and they install it and work out the big problems first. Or if it is easy, I adopt competitors packages. Bad reputations and support has burned many companies and results in delayed or lost sales. More of this is better.
Let's stop the software slide into mediocrity or unreliability as the norm. It starts with using engineering terms properly; it ends with valuing customers, their own reputations and quality. It will only change when customers demand it.
🔗 More
| |
| |
| |
Tags: Terms Tech General Tech
