This is the best software rewrite article I’ve ever read. I knew about all the stories & blog posts they reference, but the lens this author uses + the lessons he pulls out are amazing.

When I was a freelancer, I’d rewrite all the time, whether some code base I inherited, a rescue project, or even my own code bases on repeat work. As the projects got larger and more coupled (large monoliths), it became increasingly clear rewrites wouldn’t work, for all the common reasons:

• culture of company created the mess; re-doing it _just_ because Jesse Warden is there isn’t going to fix it despite my confidence
• not everyone agrees it’s a mess 😅
• we don’t have time to pause new features while we riskily redo all the existing ones that aren’t exactly the same despite Innovator’s Dilemma
• no one knows all of the features, lessons learned, how they _actually_ work, and why

blah blah blah

Sometimes, though, things were so bad, I knew it would result in only 3 options:

1. years of pain with no joy
2. a rewrite would feel good, but the same institutional problems that caused it in the first place would be there. This only was a good choice in freelance where it was deliver and leave with short timelines and fixed budgets.
3. I’d turn down the contract, knowing it was impossible for me to be successful despite assurances to the contrary (assuming I had other work lined up)

But as we know in software, there are few absolutes, and nuance is everywhere. This article pulls 6 great ones that have completely different situations.

In the past, I’ve inundated Product Owners with who were with me in these horrible situations with articles on options and risk vs reward scenarios. Many required previous context knowledge, or were old and had to be viewed in a historical context, a lot of tech knowledge, etc, making them not a really helpful tool for a PO and architect to make a well informed call on a plan forward. This article, I think, can stand alone and help do that more intelligently.