Technical debt is hard to measure and estimate. There are code quality metrics you can include. You can measure how long it takes you to implement new features. You can measure how long it takes you to land bug fixes. You can measure how long it takes to onboard new employees, contractors, and interns.
And it seems the first conclusion people come away from any such analysis is to do a rewrite.
Technical bankruptcy is no joke, and it’s hard to justify to your business no matter how bad your current metrics. How do you know this next attempt will be any better? How do you know you won’t just reintroduce the bugs of 5 years ago the last time you went through that rewrite?
Most times, you can’t know, so it’s important to have a couple simple goals.
1. Reduced surface area
You’re rewriting from scratch, so I assume you have a giant, intertangled mess. Keep that pain fresh as you architect this next round. Make your components isolated from one another so you can swap out implementations. You want your goal to be your next rewrite from scratch being just your router instead of everything. Architect for change if you want to avoid history repeating itself.
2. Plan for support
The worst part of many rewrite decisions is that it’s too easy to avoid the question of “should we rewrite” and instead decide “where can I see a clear path: ‘creating my own’ or ‘supporting what we have.'”
Few engineers cannot think of at least some green field next steps. We all have started tons of projects. A rarer skill is in assembling the tools, information, and processes to support a project. When you get a bug report, what do you do? Will you have stacktraces? How will a customer get you those? What was the current application state at the time of an error? Can you reproduce the error if the customer cannot remember their steps? Is this environmental? How should the code have behaved?
On the other hand, before going to the rewrite, you should consider if there are ways to accomplish these same goals from the current code base. Instead of rewriting from scratch, refactor or use the facade pattern to make it look like you have a smaller surface area. In my experience, this is easier than you think. Learning to support, on the other hand, is not. Unfortunately, it is also really important. Until you can learn to do this, you will be tempted by the rewrite off ramp every time.