As a result of all the data and knowledge that has been gathered, the Windows 7 team knows how good the software is. For earlier versions of Windows, a lot of this data would have to come from end-users and bug reports. Not all of it—older versions do have some telemetry courtesy of the Customer Experience Improvement Program (CEIP)—but a lot. This means in turn that the beta program doesn't have as much work to do; instead of shipping a release that probably works OK and then finding out from users if it does or not, Microsoft can ship a release that does work OK and just needs some fine tuning. Similarly, by working more closely with third parties, Microsoft can be far more confident that software and hardware alike will just work on day one.
And the entire process is easier to manage. Though the new coding approach has made it harder to get new features and new code integrated into Windows, it means that Microsoft always has a codebase that's close to release quality. In addition to the obvious reliability improvement this yields, it also makes the development process much more predictable. Essentially, Microsoft could decide "That's enough development work, it's time to release the software" at any time and, a few months later, have something ready to ship. There will probably always be the need for at least one public beta, but it no longer has quite the importance that the betas used to.
In this light, the decision to not have a second beta or Release Candidate makes a lot more sense. These broad releases are still important—not least because they allow all the third parties that don't have a close relationship with Redmond to get on board the Windows 7 bandwagon—but this time around, Microsoft doesn't need the betas to tell it if the OS works.
No comments:
Post a Comment