On August 17th, I reported that a whole slew of beta versions of the next Visual Studio (formerly known by code-name Whidbey, now called Visual Studio .NET 2005 in many flavors) had been released. In the meantime, plenty of people have had time to start digging into these betas and have been getting to know them better.
In fact, there's something of an art to working with beta code, particularly when that work is for real—namely, aimed at ultimate production use. This is a case where some caution and common sense are clearly called for, and where setting one's expectations too high is a danger that shouldn't be overlooked.
To help others benefit from my own mishaps and missteps in this environment and to permit them to pursue the seemingly contradictory goals of using unfinished tools to build a finished application (if not a finished product), please let me dispense the following advice (with nothing but the reader's best interests at heart, so feel free to dispute any of the following with me if you feel I'm leading others astray):
- Don't expect beta performance to mirror final release performance: performance improvements and optimizations are almost always part of the product tweaking and tuning that get frantically under way once features freeze, and the march toward a release candidate (and final release) gets seriously underway. Therefore, it doesn't make sense to spend time or effort in dealing with performance issues, or to worry overmuch about slow performance in beta versions of tools and languages at this stage of the game. Count on making another pass later on to address performance matters after the code settles down.
- Don't build to the most advanced interfaces in a beta version of Visual Studio. Experience teaches that such items in the environment are likely to change as the list of what's in and what's out gets finalized for release candidate delivery, or as multiple parts of complex environments become better understood, and hence, subject to revision and rationalization. In fact, I'd argue that the more advanced or exotic the interface (think about what's new, untried, and sexy, like mobile Web pages or Longhorn stuff), the more inclined to steer clear one of it that one should be, betting that it may slip into a later release or go through some changes. Look for signs of volatility in point releases, and use that to help you avoid areas that are obviously in flux. Worst case, if such interfaces are absolutely essential, give some thought and expend some design work on potential workarounds.
- Be aware that beta code is seldom stable code: the old adage from my earliest days in computing: SESO (Save Early, Save Often) springs to mind in this context. If you're going to build inside an unstable environment, get in the habit of saving regularly (at least every time you walk away from your development station, if not considerably more often than that).
With a little due diligence, lots of elbow grease, and careful navigation of sharp curves, you too can steer your way through the beta release process and take your code to a safe and stable form at the end of the release cycle next year!
Ed Tittel is a full-time writer and trainer whose interests include XML and development topics, along with IT Certification and information security topics. E-mail Ed at firstname.lastname@example.org with comments, questions, or suggested topics or tools to review.