Please let others know how useful this tip is via the rating scale at the end of the tip. Do you have a useful VB, .NET or Visual Studio tip or code to share? Submit it here.
Microsoft has been inviting people outside the company to test its software before its official release for well over a decade now. Over that time, I've watched Microsoft's pre-release software programs evolve in three ways. 1) They've grown to involve more and more people. I can remember beta programs involving a few dozen testers; now it seems as if every man, woman, child and dog on the planet has a copy of Visual Studio 2005 already. 2) They've become much more public; gone are the days when even mentioning the code name of an unreleased product could get you banned from all future beta tests. 3) Perhaps most significantly, Microsoft has grown increasingly willing to share broken software with us.
Of course, they don't call it "broken." That would give the marketeers fits. I've seen many terms used over the years. Alpha. Beta. Technical beta. Marketing beta. Release candidate. The latest type of pre-release software to come down the pike is the Community Technical Preview, or CTP. Here's the official statement on CTP builds, from the Visual Studio 2005 Developer Center:
"CTP builds do not go through the same rigorous testing that beta builds undergo. While betas receive a much higher level of testing and feature work, CTPs are intended to expose developers to the latest working build. CTPs are therefore unsupported, prerelease software and there are some precautions you should take."
Many people don't realize it, but putting out a beta build of a product like Visual Studio is nearly as much effort as shipping the final product. There are a bunch of meetings to hold. There's a concerted drive to fix bugs, so the beta will run smoothly for customers. There's a lot of extra testing to make sure things are in good shape on a variety of test configurations. There are decision
To continue reading for free, register below or login
To read more you must become a member of SearchWinDevelopment.com
s to make about which features make a beta quality bar and which ones need to be pushed back. There are freezes on checking in new code, release notes to write and a lot of general scurrying around. All of this, naturally, takes time -- time that could otherwise go toward trying to get the product ready to actually ship.
Enter the CTP. The process for shipping a CTP looks a lot like picking a date on the calendar and shipping whatever happens to be in the source code repository on that day. If it ends up being a high-quality build, great. If some things don't work really well, that's the breaks. The goal of a CTP build isn't to show off a polished product that's on the verge of shipping, but to give those of us outside of Redmond a glimpse of the product team's latest thinking: which features are in and out, what the user interface looks like at the moment, how the pieces are fitting together. We get more up-to-date information -- and the actual development process doesn't get disrupted.
CTPs are not for everyone. If you try to stay on the cutting edge of all the stuff that Microsoft is working on right now, it'll drive you insane. There are CTPs for the various Visual Studio products, for SQL Server, for "Avalon" and "Indigo," for WinFX, for the Web Services Extensions, for Longhorn, for BizTalk 2006, and probably for a few other things that have slipped my mind. There's no master coordination between CTP release schedules (like there is between beta release schedules), and installing multiple CTPs on the same test machine can easily render it unbootable. If you really have to stay current with more than one chunk of the coming software, the CTP Madness page over at Channel 9 can help you work out which builds work together. Better yet, invest some time in learning how to effectively use VMware or Virtual PC, and do your testing in virtual machines.
The best way to use CTP builds is to install them only when you have a good reason. (Personally, I don't think wanting to be the first on your block with the latest software is a good reason.) Here's my short list of good reasons for installing a CTP build:
You're doing serious work with the beta, such as trying to migrate a commercial application, and you've been blocked by bugs or missing features in the latest full beta release.
You reported a bug in the previous release and you want to verify whether it was fixed to your satisfaction.
You're writing a book or article, giving seminars, or otherwise getting paid actual cash to endure the pain of staying on the bleeding edge.
Your main interest is in seeing the most current documentation. Documentation, by its nature, doesn't break as readily as the actual software.
You may choose to set your own criteria differently, depending on your available time and energy, and your eagerness to see the latest features. In any case, I suggest waiting a couple of days after the release of a CTP before grabbing it. That's enough time for early adopters to comment on their blogs and Web sites, and you can get a rough idea of the build's overall quality. If there are real disasters lurking, you might decide to pass. Remember, CTPs are like buses: there'll always be another one coming soon enough.
In any case, I'm happy with the move to CTP builds, even though particular CTPs have caused me some pain. I see this as part of the wider commitment on the part of Microsoft to greater transparency. Along with initiatives such as the Product Feedback Center and the burgeoning number of blogs by Microsoft employees, the CTP builds are a big step towards keeping us informed about what the next generation of Microsoft software will look like months before it actually ships. That makes for easier upgrade planning and happier customers -- so long as the end product continues to be high-class software!
Mike Gunderloy is an independent developer and author working in Washington state. His recent books include Painless Project Management with FogBugz (Apress) and Coder to Developer (Sybex). You can read more of Mike's work at his Web site, or contact him at MikeG1@larkfarm.com.
