Never thought in this way, “refactor” as a “limited-scope rewrite”. Interesting point of view.

Anything that could help people going ahead and improving their software quality is valuable.

Thanks for sharing.

And the reason for this is to stop having to make a “choice” between refactor or rewrite. Code will need to be modified to best suit the business and the development model, period. Mentally, it allowed me to focus only on the scope and not in the terminology.

Normally, I like to use think about the parts of code mentioned on “knowledge silos” as snakepits: that part of your code where members on your team are afraid to even touch ot. If you have any of them on your code, and it is at least fairly important, consider giving it some attention.

Also, I would add another symptom for a “sick software” : when it is really hard to write a test for a class (and doing so requires a lot of setup).

Last, I would add that rewriting a software is a very radical decision, and if your codebase doesn’t have a nice test coverage (or documentation), you’ll for sure forget to treat some cases (not to mention that would cost a lot of time, money and effort to do so). If it is possible, I would try to rewrite some parts and toggling them on whenever they’re ready (even on a different application).