In "Things You Should Never Do, Part I", I completely agree that rewriting code is a disaster - you just throwing away hundreds of fixed bugs and introducing hundreds of new. But It seems there is another way to make system better and in the same time keep control. Refactoring (http://www.refactoring.com) is set of small-step changes that does not change your system functionally, but makes its design better. Unfortunately this works only for code that you can change and only if you have enough automated tests. In my experience, refactoring was the only things that saved me from rewriting one 50.000 line subsystem in our project. As a result we had much clear design, removed several thousands lines of code and virtually had no new bugs (most of them were fixed during refactoring and since it is done in very small steps - it is always clear where is the bug). I agree that it is better to read another developer's code than to rewrite it without understanding. But Refactoring gives you ability to understand another developer's code AND rewrite it!

Roman Eremin

-- Anonymous, December 30, 2000

Answers

Which is why a good OO design will increase productivity.

-- Anonymous, January 08, 2001

The real problem with Netscape's approach was that they didn't ship product while they were rewriting. Software businesses need to learn from physical manufacturers who overlap product offerings. At any given time they have a certain set of products available for sale, and another set being developed; some simple extensions of existing products, some brand new revolutionary products.

-- Anonymous, February 01, 2001

Is there ever a time when a code base is not worth saving?

Candidate: I work on legacy FORTRAN code. Some of this stuff is 30 years old. Not only are the original coders and designers not available, the second and third generations of coders and designers are sometimes not available. At times, I feel that the effort to understand what the code is actually doing would exceed the effort to write it from scratch. Example horror story: A 2000 line block of code with no comments, NONE!, no documentation, and variable names like X2 and YJ. My job, verify that this item does what it is supposed to do. Not only can I not figure out what it is actually doing, I don't see any indication of what it is supposed to be doing.

-- Anonymous, February 27, 2001

>Example horror story: A 2000 line block of code with no comments, >NONE!, no documentation, and variable names like X2 and YJ. My job, >verify that this item does what it is supposed to do. Not only can I >not figure out what it is actually doing, I don't see any indication of what it is supposed to be doing.

Obviously its not doing anything at all....

Sliver

-- Anonymous, March 12, 2001