Summary
Use tech debt payments to get into the flow and stay in it. Big rewrites need heavyweight support. Without the backing of management, a large-scale rewrite is likely to fail.
Once I have gotten into flow, staying in flow is so important. The tech-debt payments weren’t for some future benefit. They are helping me right now.
I avoid large scale rewrites, as I’ve seen them fail or drag on much more often than they succeeded. My biggest mistake personally was trying to rewrite a C/C++ system as memory safe C# code. But I was also part of a two-year long rewrite that worked, and learned some things that I recommend to clients.
The first lesson I learned about big rewrites was not to underestimate them. The size of the project was well-understood and planned. Contractors were recruited for their expertise in the new system, so couldn't work on the legacy one.
We coupled the rewrite with a user-facing improvement project. By the end of the project, all the non-contract engineers were working on both codebases.
If you can find a way to do it, you’ll have something to show when you�’re done, and can follow up with quality metrics after measuring them. Recruit expertise in a new technology and front-line managers that have done it before.
