On 10/26/07, Tracy R Reed <[EMAIL PROTECTED]> wrote:
> Christian Seberino wrote:
> > But why is it so important to have the new code be at parity with old
> > spaghetti code at all times?  What's wrong with it being deficient for a
> > while until it gets banged into shape?
>
> Nothing necessarily wrong with that. You can let the regression tests
> fail for a while if you want. But eventually you will want to come back
> and fix that stuff and how will you ever remember what it was that
> needed fixing? It is important that the final product be at parity with
> the old code in a case where you are releasing a new version of software
> which is just a minor revision number different and therefore should be
> completely compatible with the previous version so nobody's stuff
> breaks, just for one example.
>

Maybe the key question is this. Does anyone ever
write a new system these days?

If all we ever do is morph old systems then perhaps
all we should do for a few years is write enough unit
tests to bring those old systems up to snuff then start
from there on the endless enterprise of extension.

I have not bothered to look at the source code for say
Python or Ruby but I would hope that each is mature enough
to have accrued a large number of unit tests. Is anyone
familiar with the facts of this situation?

Gotta run now, maybe I will look into it later.

BobLQ


-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to