The State of Software Development

In the world of Microsoft, the last year has been all about .NET. Is it an improvement?

• By Mike Gunderloy
• 06/01/2003

While the state of software development is of somewhat less import than the state of a new nation, I can’t help but share some of old George’s optimism about the way things have been going lately. In this, my annual roundup column, I’m going to look back over the last twelve months, and perhaps peek a bit forward.

It’s All About .NET
For me, at least, software development over the past year has been all about .NET. Sure, I’d worked with Visual Studio .NET starting with very early betas, but it wasn’t until I signed a contract to write three MCAD training guides that I dug in seriously. Now, a year later, I’ve worked with most every part of Visual Basic .NET, C#, and the .NET Framework — and I have to say I’m impressed. I’ve moved much of my own development work over, and I’m not looking back.

(This is probably the appropriate spot to assure you that yes, I am aware of other enterprise development options, notably Java. But this is a Microsoft-centric site and I’m a Microsoft-centric sort of guy. For other people, the last year has been all about J2EE, and that’s great too. There’s been some acrimonious debate between the two camps lately, all of which strikes me as about as illuminating as burly guys growling “tastes great” and “less filling” at each other.)

Anyhow, I’ve written a pretty large amount of .NET code over the last year. Much of it is trivial example code to demonstrate one or another exam objective, but there are some bits of “real” applications in there as well. Whether it’s enumerating all of the shares on a network or hooking up databases to a Web page, it’s been a productive environment for me. Much of the credit has to go to the team that designed the .NET Framework. They crammed a ton of stuff in there that the VB .NET or C# developer gets for free, without writing any code. Many things that used to be very difficult (like creating a Windows service) are now trivially easy. Of course, a few things are harder (drag and drop, for example), but overall most everything moved in the right direction.

Judging by the number of utilities — commercial and freeware — that have come out for .NET, I’m not the only one who feels this way.

But Is It an Improvement?
This is, after all, supposed to be a column about improving software development. So, does moving to .NET allow people to write better software? Well, yes and no.

As I said already, many things have gotten much easier in the .NET universe. If you’re trying to pass relational data between tiers or check the value of a performance monitor or secure code so that only certain users can run it (to name just a few possible tasks), the classes in the .NET Framework can do the job. This has the prospect of making you much more productive than you were with any previous Microsoft programming environment. Hopefully, with improved productivity you can pay a bit more attention to things like quality control. The Framework itself is quite high quality (though, inevitably, there are some problems; see the .NET Bugs Registry at http://www.jelovic.com/dotnetbugs/index.html for some examples).

But while making it easier to perform superhuman feats of programming, the .NET Framework has also made it much easier to shoot yourself in the foot if you don’t know what you’re doing. Take Web Services, for example. Web Services are great for distributing applications across the Internet and for interoperating between various platforms and languages. But all too many developers who don’t know what they’re doing are creating Web Services that don’t interoperate well or that are dog-slow because they try to pass too much data. Sure, you can serialize an elephant if you want (at least, you can if you implement ISerializable in the elephant class), but don’t expect it to get delivered quickly over a dialup connections.

But that’s always the pattern with new technologies. Windows itself made it much easier for many developers to create an attractive GUI — and easier for other developers to create hideous, non-standard user interfaces. Technological power needs to be leavened with experience and thought in the programming business.

Effective .NET
So, given that you want to write high-quality software, what do you do to increase your chances of doing so with .NET? I’ve got three recommendations here.

First, learn to actually use .NET. It’s not VB with a few tweaks and it’s not a minor upgrade to MFC. In particular, you really need to spend some time browsing around in the .NET Framework, so you can understand all the things that you don’t have to write code to do. More than once I’ve pointed out to a new .NET developer that they’re expending a lot of effort on something that would be a one-liner if they instantiated the proper class. In addition to the SDK reference material, you might find a book such as the O’Reilly’s C# In A Nutshell useful in giving you a paper Framework reference to page through.

Second, investigate the tools that exist to extend .NET. Although it’s a young environment, there are already dozens of things that plug into the Visual Studio .NET IDE. These range from high-end UML tools like Rational XDE down to freeware code-generation tools like CodeSmith to designers that make creating strongly typed collections a snap. Browse through back issues of MCP Magazine Developer Central or visit my site at http://www.larkware.com/ and you’ll find dozens of these tools.

Finally, don’t neglect the basics. No matter how spiffy the development environment, you still need source code control. You still need daily builds. You still need to track requirements and bugs. You still need a project plan, and good communication between team members. For many of these tasks, there are now tools that integrate well with .NET. Just don’t make the mistake of thinking that you can skip over this stuff because the environment is so productive.

And on the Horizon?
With Visual Studio .NET 1.1 released, it looks like we’re going to get a bit of a breather on new tools from Microsoft. SQL Server “Yukon” will be in beta soon, but I’ll be very surprised if it actually ships before 2004. Office 11 shouldn’t be out before late in the year either.

So, my advice for the moment is to take the time to consolidate your gains. If you’ve been planning a .NET migration, things are stable enough, and the tool support is good enough, to get started. If you’re thinking about tweaking your development process, go for it — maybe you’re ready to try some agile methodology, or at least get that daily build stuff going? Above all, have some fun and concentrate on writing high-quality software. And yes, I do think those two things go hand-in-hand. That’s what makes this such a great business.

Of course, last year at this time I was speculating that we were finally getting the upper hand over worm writers — and SQL Slammer came along to prove me wrong. But why wait a year? Write me now and let me know what I’m missing on the current software landscape. I’ll use the most interesting comments in a future issue of Developer Central.

Want to read more of Mike’s work? Sign up for the monthly Developer Central e-newsletter, including product reviews, links to web content, and more, at http://lists.101com.com/NLS/pages/main.asp?NL=mcpmag&o=developer.