Editor's Note

Five Years Sees Progress, Work Ahead

History and future of .NET.

• By Patrick Meader
• 03/01/2005

Five years into its life, .NET still feels like a nascent technology in many respects. Part of the reason for that is that we're still waiting for the first major upgrade to hit the streets in the form of Visual Studio 2005 (code-named Whidbey). (Yes, Microsoft released Visual Studio 2003, but it was more of a stopgap release in preparation for a larger plan, much as VB2 and VB6 were.) Another reason .NET feels like a nascent technology is that we're still in the early stages of a march toward service-oriented apps, and many of the pieces just aren't in place yet. Also, the progress in VS.NET is less discernible over time because it was far more complete when released than Visual Basic was, which only hinted at the power it would eventually provide developers.

.NET still elicits the claims that it is both too hard and too easy to use. At one end, you still hear complaints about the complexity of the framework and how long it takes to become familiar with. In many cases, developers simply haven't, choosing to stick with VB6. How many? Official numbers are hard to come by, and the numbers I do hear cited are so varied as not to be meaningful. What can't be disputed is the effort you see Microsoft making to attract this developer. Visual Basic .NET 2005 introduces My.Classes and, of course, the rebirth of edit-and-continue. Together, these features should give .NET a more VB Classic–like feel, but I don't really believe these features will be a difference maker for those still using Visual Basic 6. People won't move from earlier versions of Visual Basic unless they perceive they must.

At the other end of the spectrum, I still hear from developers and readers who complain that .NET makes some kinds of development too easy. For example, they cite the ease with which you can implement Windows services, asserting that it isn't always a bad thing that some things are hard to do, especially if it keeps people from writing a service to notify them every time the toast is ready or the cat box needs to be changed. They maintain the ease of implementing this functionality leads to maintenance concerns far more significant than not being able to write a service or implement inheritance in the first place.

Concentrating on the functionality you want to implement is what development is all about. I suspect the real reason people care about some things being too easy is it makes it harder for potential employers to tell skilled developers from less skilled developers if both can claim the ability to write the same kinds of apps. Which leads to a significant concern among many developers: Few developers I know earn as much now as they did when VS.NET was released. It would be simple-minded to say that .NET is the main reason for that—the burst of the Internet bubble, the general recession in technology, and the increased reliance on outsourcing certainly play a role here—but it's human nature to look back at the milestone that marks the release of .NET and compare what you had then to what you have now.

Five years into .NET's release, and a magazine name change later, I still think VB.NET and C# were both critical steps in the right direction for Microsoft. Visual Basic 6, for as long as some developers have stuck with it, was seeing its base erode to tools that had stronger innate Internet-related capabilities (read: Java), and C++ might be powerful, but from a productivity standpoint, it gave up many things to Java, as well. .NET provided both Visual Basic and C++ users with important new capabilities to write the kinds of apps sought after in the marketplace faster and more easily. A lot of work remains, but much has already been accomplished. At VSM, we're looking forward to helping you manage the next five years.