Filling a Green Field

Developers commonly make the following two statements:

The first statement is known as having a "Green Field." The idea is that when you start from scratch, it's like constructing a building on an empty lot as opposed to renovating an existing building. This term is often heard in relation to rewriting COM code to .NET code. However, in response to my last column ".NET Now Positioned to Replace COM" (http://www.sqlmag.com/articles/index.cfm?articleid=93767&), a reader informed me, in no uncertain terms, that, "The people in the industry that tended to be disgruntled were the ones that couldn't see the wisdom in rewriting code to be 32 bit from the ground up." However, the Green Field comes with its own risks--risks that have been well illustrated in computer history.

For those of you unfamiliar with that history, let's use a simple example. Initially, Netscape was the browser leader. It then decided to rewrite its entire browser from the ground up. This was right around the end of the transition from 16-bit to 32-bit OSs, and part of the plan was to remove all the legacy code in the next version of the browser. To make a long story short, Netscape 5.0 never shipped, and by the time Netscape 6.0 shipped, its market leadership was a thing of the past. Don't get me wrong--the browser still exists. But let's be honest: How many of you have tried Netscape 8.0?

This brings us to the second statement I made in regard to Microsoft software and bugs. Now, you might not like Microsoft and you might complain about its software, but you should be willing to learn lessons at Microsoft's expense. First, let's recognize what the market illustrates. Microsoft knows how to ship software and knows how to create good software. Yet even Microsoft introduces bugs and omits needed features when it releases new software. What makes you think your organization will do any better?

I bring this up because the most popular statement from application developers is, "Let's rewrite it from scratch." The idea that we can do it better if we just start over has been proven not be true time and again. Don't get me wrong--there are situations in which you might have to throw away an application for business and technical reasons. However, attempting to rewrite an application (as opposed to rewriting a feature in it) from scratch just because you think you could do it better is almost always a bad idea.

In terms of the developer's day, updating software is harder than trying to write software from scratch. But you should remember that although old code often looks ugly, it has one key advantage: It runs. The old code has been debugged and, in many cases, has obscure patches for unexpected scenarios that you'll spend weeks figuring out again. Rewriting code from scratch is something you should do only in rare cases. Take the approach that today's green field is tomorrow's green swamp. A complete rewrite might seem easier, but history shows that it's a mistake. Think about this: Why did Microsoft build in several tools to help with migration to .NET? Because they thought everyone understood the danger of rewriting applications from scratch.

Finally, as an example of the potential pain of migration, consider that Microsoft needs to get Visual Studio 2005 working on Vista, a 64-bit compatible OS. I want to be clear--the challenges aren't with .NET applications, but with the application Visual Studio 2005. Given what S. Somasegar writes in his blog "Visual Studio 2005 SP1 Beta and Visual Studio support for Vista" (http://blogs.msdn.com/somasegar/archive/2006/09/26/772250.aspx), Microsoft isn't finding it easy to get its developer tools running on this new platform. This blog mentions that Microsoft recently released a Beta version of Visual Studio 2005 Service Pack 1 (SP1). You can expect the release of this service pack in the next three or four months. If you're interested in the beta version, go to http://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=3311.