Back Draft
The Meaning of Beta
By Jonathan Goodyear
Five years ago, if you asked the typical office worker what beta software was, most of them would just sit there and look at you quizzically. Even those who recognized the term usually knew little more than it had something to do with software that hadn t been released yet. Beta software usage was almost completely under the purview of an exclusive and well connected group of developers and other software professionals.
Then Microsoft changed everything. They upset the apple cart by exposing the world at large to the wonders (and evils) of beta software. The objective was simple: Expose as many people as possible to early versions of their new software (such as Windows Vista and Microsoft Office) and cull the mountains of feedback for trends that would not be available with a smaller testing sample. Of particular interest was information regarding the experience of normal non-technical people while using the software. The resulting feedback could then be used to make Microsoft software even better right out of the gate.
Microsoft has been pretty successful at using beta testing cycles to improve their software development process and initial product quality. However, a side effect has been the proliferation of the term beta software, as well as an alternative (but quite incorrect) definition and understanding of what beta software is. To many non-developers who are in the business of producing software (as is the case with many entrepreneurs), the idea of beta software is appealing because it offers the prospect of getting software into customers hands earlier. Unfortunately, these non-developers and their customers have no idea what s in store for them, which can cause a lot of finger pointing on both sides of the fence when things go wrong.
The misconceptions about using beta or incomplete software in production are so widespread that a well known consulting company created a satirical television commercial to poke fun at it, while advertising their consulting services (http://video.google.com/videoplay?docid=-1959414077447924569&q=EDS+commercial+plane).
With all that in mind, the purpose of my column this month is to help set the record straight on what beta software is, and what it is not. I have done it in the form of a list of the 10 beta software laws:
- Law #1: Beta software is not production software. It should not be distributed to anyone who may mistake it as such.
- Law #2: Beta software will crash, and crash often. If beta software did not crash, it would be called production software.
- Law #3: You should not rely on beta software to get your job done. It may not be there for you when you need it.
- Law #4: Beta software does not have to play well with others. It has free reign to crash any of the other applications on your PC (or your PC itself). It may also force you to re-image your PC.
- Law #5: Beta software does not have to have a smooth upgrade or uninstall process. You should be prepared to lose all your application data (especially between beta releases).
- Law #6: Beta software is not feature-complete. Grayed-out menu options and buttons that launch message boxes that say Not implemented yet (or worse) are the norm.
- Law #7: Beta software is rarely supported beyond e-mail, forums, and newsgroups. Not even Microsoft deviates from this law.
- Law #8: Beta software is not demo software. Demo software is production-quality software with licensing or usage limitations placed on it. Beta software simply isn t done yet.
- Law #9: Beta software is not a marketing tool, unless buggy, unstable, and incomplete software are attractive qualities to your customer base. Only existing, well known, and forgiving customers should be beta testers.
- Law #10: Murphy s Law, which covers everything else that I haven t mentioned above.
When you deviate from or ignore these beta software laws, bad things can happen. For instance, if you release your beta software to someone who is not versed on what beta software is (or the laws that govern it), then they ll almost certainly complain about application crashes, loss of data, and general application quirkiness. These same users will probably not think to install this beta software on a non-critical PC, or use Virtual PC/VMWare (not that they would even know what those are).
A common theory is that if you are building an ASP.NET application, you can avoid the pitfalls of beta software, because there are no installation or other issues pertaining to how your software interacts with its local host environment (e.g., the browser). You still run into a problem, though, if your users think it is a production application. That is because you now have to make the various iterations of your beta software compatible with each other to match customer demands. The enormous effort of building version upgrade scripts will bog down your software development process.
This column is not meant to scare you, your boss, or your clients away from using the beta software process. Beta testing cycles can lead to invaluable feedback that can help make sure that your software will hit the mark with your customer/user base. However, it is very important that all parties involved in the beta process completely understand the ramifications of what they are getting into. Otherwise, the eventual outcome will be bad no matter how much beneficial beta testing data you collect.
Jonathan Goodyear is president of ASPSOFT (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, an ASP.NET MVP, a Microsoft Certified Solution Developer (MCSD), and co-author of ASP.NET 2.0 MVP Hacks (Wrox). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at http://www.angryCoder.com.
