Software Rewrites

2/6/2004 3:57:31 AM

Software Rewrites

I have, in the past few weeks, read two articles on software rewrites, one in SlashDot called "Rewrites Consider Harmful," and another from Joel called "Things You Should Never Do, Part I." Both take rather strong positions against rewriting code.

Each mentioned Netscape's fatal strategy to rewrite Netscape 4.0. Joel alluded to Microsoft's own failed rewrite of Word called "Pyramid" that resulted in an effective stagnation of Word development for a year and a half in the early 90s. As a result, WordPerfect had mustered technical leadership in wordprocessing for some years after that. Fortunately, a small group of Word developers continued working on the older codebase focusing on a number of "ease of use" and intellisense features, and Word was able to come out with another version.

In some cases, I do believe "rewriting" to actually be beneficial, such as in the development of new technology with a lot of unknown. Avalon, the port of the Windows API to managed code, comes to mind. .NET Framework is still relatively new technology with few heavy-weight commercial shrink-wrapped packages currently running under it; the performance characteristics of the runtime are still undetermined.

After two years of development, Avalon underwent a complete rewrite beginning last spring to address performance and complexity issues. These issues had less to do with inherent problems with the runtime, and more to do with understanding performance bottlenecks in .NET as well as general issues of designing an object-oriented framework. I think that was the right decision, because Avalon is supposed to be a long-term platform from which all applications will be built on; it needs to be done right.

Rewriting makes less sense with an existing product, where there are urgent business considerations and heavy competition.

In the course of developing my software, there have been a number of modules that I had completely rewrote, and, in one particular case, I rewrote twice. I actually did some design work before starting implementation, but still it was not enough to foresee the need for a rewrite. Since this is an entirely new product, it doesn't really fall into the category of rewriting existing products that, I think, Joel and Slashdot are referring to.

I know some of you out there may actually believe the rewrites to be a failing in my part. However, I believe that software is an iterative process, that initial designs often don't survive the coding process; I have seen this borne out frequently at Microsoft. In addition, the rewrites resulted in code that dominated the previous code in virtually every area--maintenance, performance, reusability, quality, and reliability. I think that the initial coding exercise provided me with a better understanding of the problem, and that rewrites should really be considered of a part of development process. I certainly believe that that the total time for development would have been greater if I hadn't rewritten.

That said, there is a danger in doing rewrites. In pursuing engineering excellence, it's possible to forget business needs. Sometimes, the winner is the company with the shipping product!






Net Undocumented is a blog about the internals of .NET including Xamarin implementations. Other topics include managed and web languages (C#, C++, Javascript), computer science theory, software engineering and software entrepreneurship.

Social Media