This is perhaps one of the greatest articles every written on software rewrites. Every single developer should read and understand what it is trying to say.
...but the reality of green field projects is that they create the illusion that your messes don’t matter. Your messes do matter. Every single one of your messes matters. And if you don’t clean them up from the very start, you are going to wind up with a horrible messy legacy wad in short order.
How true. Few years back, I went through most of what is written in the article. I watched two systems, built to replace the same system before it, one after another. We fixed some messes but didn't quite understand what we were trying to overcome. Each new system got out of date and messy faster than the previous one!
This was also the reason for me hiring the architect for my new home. She walked around the old place and asked us about our messes, habits and workflows:
Why do you have a chair here? Is this where your mail pile up? Why do you take work calls from the sunroom?
Nowadays, whenever I hear about the need for a rewrite, I dig into understand issues in-depth. They often surface smaller pieces to fix.
Why is it hard to deploy? Let's run through a recent feature, why did it take so long?
Couple of other questions I ask:
Where do the rubbish pile up in the system? (example: are all the AB tests wired in your REST API and it is a monster...) What system do you have in place to collect the rubbish periodically?
Lastly, my colleague @Anuraag used to say:
Is your rewrite trying for a revolution or evolution? Definitely don't attempt a rewrite if you are looking for an evolutionary change.
Keep this in your bookmarks. Read it often. Share it with everyone. Thanks @JoeS for sending this to me few years back.