If you know that you're possibly keeping the code, you do things in a "proper" way, which means moving slower. Put in all the exception handlers, all the log statements. Structure the code nicely, refactor things while you're in there, modularize them properly. After all, it's going to be reused.
This is where it all comes from. You don’t have to throw away code if it doesn’t need refactoring, modularization and so on to satisfy that “reuse” mantra from the beginning. Healthy reuse comes in two flavors:
- a copy of the code
- a separate well-maintained, versioned and documented library
Anything reuse-focused in between is mostly snakeoil not worth drinking and is often the reason why your code has so many intricacies in it that you have to perform “recon missions” before actual coding or estimating. You’ve built a dozen of poorly-documented ad hoc libraries into your project. There’s no surprise it may require a proper source code expedition to detect and recrystallize parts that a new requirement shattered this time.
Eh, don't get me started on how many people take a well known abstraction then build another abstraction on top of it. You already had the abstraction!
This is where it all comes from. You don’t have to throw away code if it doesn’t need refactoring, modularization and so on to satisfy that “reuse” mantra from the beginning. Healthy reuse comes in two flavors:
- a copy of the code
- a separate well-maintained, versioned and documented library
Anything reuse-focused in between is mostly snakeoil not worth drinking and is often the reason why your code has so many intricacies in it that you have to perform “recon missions” before actual coding or estimating. You’ve built a dozen of poorly-documented ad hoc libraries into your project. There’s no surprise it may require a proper source code expedition to detect and recrystallize parts that a new requirement shattered this time.