Dave Donaldson

As a lot of people are doing these days, I'm spending a decent amount of time with the Beta 1 Whidbey bits. There's tons of good stuff coming next year in .NET 2.0 and VS2005, and I particularly can't wait for Beta 2 and the GoLive license for ASP.NET.

As I was digging into the new ASP.NET 2.0 Membership API, something occurred to me: why not use the designs of the future stuff in today's applications? Think about that for a second. With each new version, software gets better (usually), especially in regards to development platforms. Annoying bugs have been fixed, new features have been added, APIs have been cleaned up, the tools get enhanced, and so on and so on.

Why not use the knowledge of what's to come in your job today? This can have a major advantage for you down the road when the next version is ready. And I'm not talking about using ideas from the future stuff in only new applications. Take those future techniques and begin applying them to your existing applications by using simple refactoring and testing methods. Of course, I'm not saying to do it just to do it. Obviously you need to do some critical thinking and determine what makes sense. But to me, you can take advantage of the future work that's being done today without adding a lot of risk to your existing apps.

For example, as part of the MSDN Mag article we wrote, Steven and I built the NavPath control. The entire design of the control was based on the new SiteMapPath control in ASP.NET 2.0, but we wrote the control in .NET 1.1. We studied the API of the future stuff, learned its ins and outs, and built a version of that control using today's technologies.

Another example: I'm working on a side project right now that deals with membership and user data. All of that functionality is working as designed and tests well. But as I started playing more and more with the new Membership API in ASP.NET 2.0, I realized that the future way of handling membership tasks is a little cleaner than how I'm currently doing it. So I've decided to refactor my design to better match the design of the future.

Also think of this overall concept in this way: if you can start implementing certain aspects of a future design today, you'll be way ahead of the everyone else when the time finally comes to upgrade/migrate to the new stuff. For instance, in my side project I'm now creating a class named Membership that contains many of the same methods found in the Membership class in ASP.NET 2.0. So when the time comes for me to upgrade to the new stuff, I can simply change a namespace reference, modify a couple lines of code, and run a quick test to verify all is still working as expected. No major overhaul or code rewrite.

The point is I know most people don't mess with beta bits too often. And why would they? They've got real work to do and most people don't get paid to play with beta code that's 6-18 months away. But I've found that most of the techies who are responsible for driving adoption of techologies do play with beta products for the sole purpose of knowing what's coming down the road so that they can plan/adjust/react accordingly. All I'm saying is that for those people to now take that knowledge and begin applying it to today's applications. That's the hidden advantage of beta bits.