> You may discover as you work in the subsystem that maintaining it is simply untenable — and it may be time to consider rewriting the subsystem from scratch. (

> You may discover as you work in the subsystem that maintaining it is simply untenable — and it may be time to consider rewriting the subsystem from scratch. (After all, most of the subsystems that are in the first category replaced subsystems that were in the second.) One should not come to this decision too quickly — rewriting a subsystem from scratch is enormously difficult and time-consuming. Still, don’t rule it out a priori. It's good to see this important trade-off mentioned. I've seen Spolsky's infamous allegory about Netscape [1] that "[rewriting] the code from scratch [... is] the single worst strategic mistake that any software company can make," used to browbeat people in response to their quite justified opinion that "maintaining it is simply untenable." While Spolsky does go on to nuance his statement a little bit, advocating for a careful refactoring process with lots of tests, I was happy to see the same advice formulated in a way that precludes such cherry picking here. [1] http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html