A Look at .NET

Like it or not, .NET is changing the face of development with Microsoft tools. Let us sort out the pros and cons of being an early adopter to this new technology.

• By Mike Gunderloy
• 02/01/2002

In the minds of some folks at Microsoft, there's really no question to be answered here. They've been using .NET internally for so long and pushing it at the rest of us so hard, that they assume everyone will switch. It's the latest and greatest platform, it makes development easier, it's got cool new tools, and it even does Web Services! But to assume that every developer who uses Microsoft products (let alone all those developers using competing products) will embrace .NET is simply naïve.

One of the nice things about software development is that a competent developer can make a living using many different tools. I know several people who have built successful consulting careers by developing applications in Access 97, and who still do so despite the release of later versions. The FoxPro community is large and vibrant despite years of more or less benign neglect by Microsoft. SQL Server 7.0 still has a huge installed base despite the improvements in SQL Server 2000. These are just some of the obvious examples; if you hunt around, you can find even smaller development niches, some using obscure or "obsolete" languages, where people still make a living by delivering software that delights their clients. So, to switch or not to switch?

Your job as a developer who needs to earn a living is to weigh the costs and benefits of moving all or some of your work to the .NET platform. When you're doing so, you need to try to discount the hype. This can be difficult, because whatever you might think of their software, Microsoft is extremely efficient at creating buzz around a new product. If you just judge by the sheer number of .NET books, articles, and Web sites, you'll get the impression that this is an unstoppable juggernaut that all the cool kids are already using. In truth, authors write about .NET because that's what editors want to buy, and editors want to buy things about .NET because that's what they think they can sell to readers. And why do they think that? Because Microsoft has assured the editors that .NET is The Future Of Software Development. Now, that might very well be true—or it might be that those of us in the press are being conned into creating the interest that we've been told is already there.

The Costs of Switching
Because there's already been plenty of ink spilled about the benefits of .NET, let's start with the very real costs of deciding to switch.

First, of course, there's the cash price of buying the software. I haven't seen release pricing for Visual Studio .NET yet, but it's easy to set an upper bound on what you'll have to spend: VS .NET Pro will be included in MSDN Professional subscriptions at $1,200. To get the top-of-the-line VS .NET Enterprise Architect you need to move up to MSDN Universal at $2,800. Check out the MSDN web site at http://msdn.microsoft.com/subscriptions/
prodinfo/pricing.asp to see some available discounts on these prices. The bottom line is that it won't cost you more than $1,200 to start writing serious .NET code. While that's not exactly lunch money, it shouldn't be too big a hit for the average independent developer or reasonably funded IT department to spring for (VS .NET should be somewhat less expensive alone than packaged with MSDN).

More important in terms of cost is your time. You should plan to spend hundreds of hours just getting familiar enough with .NET to write applications that are well designed, and thousands of hours to become a real expert. This will be a long-term project. But you need to be aware that there are a lot of new concepts in .NET, and new ways of doing things. Your experience with previous Microsoft tools won't prepare you for the complexities of .NET. Plan on spending some time reading articles on Web sites, newsgroups, and magazines, and spending some money on books to supplement the .NET documentation as well. One caution on the latter: All of the first round of books were written from beta code, so they inevitably will contain information that's just plain wrong in the release version.

You also need to consider the problem of migrating existing applications. Here you've got a variety of choices. First, you can upgrade existing VB or Visual C++ applications to .NET with a minimum of pain, and then worry about rewriting them to be more efficient. Second, you can use the .NET interop features to bring new code into an existing application one piece at a time: COM applications can call .NET components and vice versa. Third, don't rule out the possibility of leaving existing applications where they are and just writing new stuff in .NET. It's not like previous code is going to suddenly go stale.

Finally, the chances are high that most serious developers will hit bugs in .NET that will take time to figure out. Yes, this is so despite what is undoubtedly the largest developer-tool beta ever. Based on past experience, it's clear that some subtle bugs will remain, whether on untested hardware or with new versions of the operating system, or just because beta testers don't think to try everything. Of course, you have to pay this price with existing tools as well. The difference is that you probably already know where most of the bugs are in those tools.

The Benefits of Switching
What can we put on the other side of the balance to counteract those costs? First, don't discount the fact that working in Visual Studio .NET is just plain fun. Microsoft really has learned how to design IDEs over the years, and VS .NET makes great use of screen real estate to cram in lots of information without feeling cluttered. The tools are strong and the rapid development capabilities are a joy. Want to display the contents of a database view in a grid via a Web service? Once you know what you're doing, you can demo this in five minutes. The demo code isn't so far off from production code, either. With luck, the time you save in writing code faster will balance off the time that it takes to learn .NET well.

Second, the marketing push goes far beyond developers to reach our customers. Web Services in particular are getting lots of marketing buzz right now. The pointy-haired boss contingent is going to be demanding Web services interfaces for everything so as not to fall behind the competition. If you can step up and write them, you should be able to find business without too much trouble. But remember the lessons of the dot-bomb bubble, and take your payment in cash instead of stock options. Just because everything can be delivered as a Web service does not mean that there's an economic advantage to doing so.

Third, it seems likely that learning .NET will provide you with solid tools for developing applications for at least the next couple of releases of Windows. Assuming that it doesn't get whacked down hard by the legal system, Microsoft will continue putting .NET hooks—from Passport integration to shipping the .NET Framework—directly into the operating system. This ensures you of a lot of desktops that can potentially run your application.

Fourth, some early adopters will manage to make a name for themselves as experts. If you're one of those people, you'll find that it pays off in training and speaking engagements, quick (but high-prices) consulting gigs, and book contracts, if not in groupies. Some folks have built successful careers on previous waves of Microsoft software in this way, without actually having any paying corporate clients. You could be next.

Minimizing Your Risk
Microsoft hopes that the switch to .NET will be like the DOS-to-Windows transition: something that gathers momentum and pulls everyone along. On the other hand, it could turn out like Access 97-to-Access 2000, with the new features not compelling enough to be worth the time, expense, and increased disk footprint for many developers. I don't think you can afford to ignore .NET at this point, but what can you do to minimize your risk whether Microsoft is right or not?

For starters, bite the bullet to learn about .NET. At least get yourself a copy and sample the extensive documentation that comes with the .NET Framework and Visual Studio .NET. You might end up with an "aha!" experience over some part of it that looks perfectly tailored to solve an existing problem. Books and articles don't substitute for playing with the software; if you're on a limited budget, I expect Microsoft will be giving away the Learning Edition for next to nothing.

Next, think about your target market. Are you a corporate developer? You may not have the choice of tools, but you can certainly advocate for the tools that work best for you. Are you in a niche market? Is the competition leaping to .NET? Do you need to join them to compete, or can you skim off customers who are reluctant to upgrade? No one knows your market as well as you do, so one-size-fits-all recommendations won't work. Set aside as much of the hype as you can, and ask yourself honestly what you can sell most effectively: .NET or applications developed without it?

Finally, whichever way you jump, have a fallback plan. If you do invest heavily in .NET, don't burn your bridges. Keep supporting existing code. I recommend forking your development tree, rather than just ceasing non-.NET development. On the other hand, if you don't make the transition right away, make an attempt to position your effort with your clients. Don't sneer at .NET and give them the impression that you've got no interest in what's new. Rather, you're evaluating the new platform and will help them upgrade when it makes sense for their applications. That might be never, of course, but it might be helpful to have the opportunity. Otherwise, you run the risk of the clients going elsewhere when they become determined to have a Web service of their very own. Remember, your goal isn't necessarily to write the code that they need, but the code that they want (and will pay for!).

Any way you look at it, we're in for some interesting times in the development industry over the next few years. For my own work, it's clear that .NET will have a significant impact. But remember, I spend more of my time writing about code than writing code these days. You need to make your own decision, not listen to what some pundit has to say about the mythical "best" way to develop.