Windows Confidential
How Betas Became RCs
Raymond Chen
Back in the old days of Windows®, prerelease versions of the product followed a fairly standard progression. First up were the alpha releases, which were used internally and possibly shared with software development partners outside of the Windows product team.
After alpha releases, there naturally come beta releases, which are sent to a somewhat broader audience. One major difference between alpha and beta release users is that beta releases include people who aren't software developers, such as end users who like to test prerelease software and corporations who want a head start on evaluating the new OS to determine the compatibility of the new product not only with their critical in-house applications but also with their corporate network, standard hardware configurations, and system management tools.
Finally, you had release candidates. These were, as the name suggests, versions of the code that were candidates for final release. In other words, "If everything goes well, we're shipping this puppy." If some horrific bug was found that invalidated this expectation, then as soon as the bug was fixed, a new release candidate build was spun up and the test cycle restarted. Windows 95 shipped its sixth release candidate.
I'm told that the Windows NT® folks followed the same release naming pattern, but they ran into a problem: corporations didn't bother testing their critical applications against beta releases of Windows NT. The logic generally went something like this: "Why bother? It's just a beta. Betas are for fanboys. It'll all be different in the final version anyway. Any testing we do now would just be a waste of time."
Similarly, software companies paid no attention to issues found during the beta testing of Windows NT. "We don't support beta operating systems," they would respond.
These companies would start testing in earnest once the actual release candidate builds came out, and they'd inevitably find a bunch of problems. Some were problems the companies could address on their own, while other issues were more complex and had to do with Windows NT not being "compatible enough" with the previous version of the operating system. There were minor issues with the way a particular project feature worked, and some of these could sometimes be fixed in a short period of time. But some issues were so serious that the product's release was delayed so the team could resolve the problem.
These release candidate builds also generated a lot of suggestions. We received feedback such as, "We think the UI would look better if you arranged the buttons in this way" and "rephrasing this message would make it less confusing for our employees." Those would have been great suggestions had they only arrived during the beta phase, but by the time the first release candidate is rolled out, it's far too late to start making changes to the interface design. The documentation and help files have already been written, the product has been translated into dozens of languages, and the screenshots for the manual and product box have already been laid out, tuned, color-separated, and printed. All that work isn't going to be thrown out and redone just to move a button.
I recall a meeting during the Windows XP era when one of these last-minute changes was being debated. The proposed change would have required that a 20KB help file be altered so that the instructions corresponded to the new UI. The localization and translation representative informed us that re-translating the modified help file under the extremely tight time constraints would cost hundreds of thousands of dollars.
To counteract the attitude that betas don't count, the Windows NT team resorted to grade inflation. There are still beta releases, but the late beta releases—when there is still time (but not much) to do some fine-tuning—have become known as release candidates, and what used to be release candidates are now escrow builds. The term escrow does a good job of conveying the true state of the build: "It's over, and we're not going to touch it unless there is a real emergency."
Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. He thinks he can see his house from up here.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.