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
- February 01, 2002
Like it or not, .NET is changing the face of development with Microsoft
tools. In this column, I'll try to help you sort out the pros and cons
of being an early adopter of the new technology and give some strategies
for minimizing your risk whether you leap to .NET or not.
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.
|Bite the bullet
to learn about .NET. You might end up with an "aha!" experience
over some part of it that looks perfectly tailored to solve
an existing problem.
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
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
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.