Subj : Re: Is well written code a rare species ?
To   : comp.programming
From : Phlip
Date : Sat Aug 13 2005 12:34 am

Bob Day wrote:

> That's the wrong place to start.  First you need to write a fresh
> functional specification for the program that includes all of the
> features you want it to have, and how it should operate.  Then
> you can work on a new design of the program.  Then, having
> gone to all that effort, do a complete rewrite of the code.

There's always a tradeoff between repairing and rewriting a design.

For example, a given peesashit codebase might contain a big investment in 
debugging to push in dozens of business rules. Extracting those rules is 
non-trivial. Either you just volunteered for the business analyst role, 
"write a fresh functional specification", or you commit to deciphering the 
code to find all its rules. The goal is to leverage the existing investment 
without wasting too much time.

During such a rewrite, you have a blackout. You cannot release frequently 
during the blackout, so releases must come from the legacy codebase. So 
customers awaiting new features must await you rewriting all the ones they 
already enjoy.

Suppose, instead, your team agrees that these costs and benefits favor 
repairing the existing code. Now you must retrofit unit tests, and 
incrementally morph that code towards the better design. Incremental changes 
allow you to incrementally discover the latent business rules, and to 
continue serving releases as the design gets better.

Repairing legacy code is just one more tool in my toolbox, alongside 
rewriting. And because I am very good at design, the repaired legacy code 
will achieve a good design, too.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!!

.