in reply to rebuilding working code
Plan to throw one away refers to prototyping. If you don't prototype, you'll write and re-write as much code, in debugging and ading features ... except you'll be doing it with released code.
The other side of the coin is second system syndrome. It's discussed in Joel Splosky's article Things You Should Never Do. The basic idea is that you decide an evolving program has become so crufty that it can't be repaired or improved, it has to be totally re-designed and re-written. Nine or ten years later, Netscape 6 becomes available. The problem is that you are starting over, generating a totally new product, just like your competitors do ... except you have to remain compatible with your features while they don't.
The correct solution, according to Joel, is to adopt the eXtreme Programming concept of refactoring, that is, extracting code and encapsulating it into a routine. refactoring is inlining in reverse, if you know C++.
That is, instead of throwing it away, baby and bathwater and all, improve things, one item at a time. Take repeated code and convert it into a routine. Take a bunch of related routines and turn them into a module, or an object. Once concepts are separated, it becomes simpler to benchmark things, and replace a module with a different implementation, a different algorithm.
Of course, you need testing to determine whether changes break existing requirements. But you'll only regret writing tests until the first time you go back to do maintenance on existing code, and find you can verify correctness in a fraction of the time. Anyway, that's a topic for a different Seeker of Perl Wisdom.
--
TTTATCGGTCGTTATATAGATGTTTGCA
|
|---|