80/20 Deprecation
Deprecating legacy software is a hard problem and one faced by almost every professional developer. Adding things is often the easy, exciting, glamorous part; spinning up a new service to replace legacy work feels amazing. It's easy to believe that this was definitely the "right" decision to pay down tech debt. And oftentimes, the team that begins one of these projects will receive praise from leadership (or, at least, their local management) for moving fast and "taking ownership" of their code while still delivering business value. Unfortunately, in my experience such praises come in the early-to-middle stage of the project. Nothing has been "finished" or "deprecated" yet, but the team has already been rewarded with their due of notoriety. The incentive to carry the work to completion, to finish not just the 80% but also the 20%, is now much lower. Who's going to care? Once they've been called out for doing good, it will only reflect poorly on them if they're seen still working on the same thing 6 months later ("Wasn't this already done 6 months ago?" "Don't you have other things to work on?"). If you do move on early, then you're going to be stuck maintaining the remanants of the old system in addition to the new one. Features may need to be developed twice, and the institutional knowledge tied to the old system has to live on. What has really been gained?
How do we overcome the inertia required to finish the 20%? It rarely seems to end up on the roadmap, and those continuing to face this issue probably don't have a great system in place for tracking how much time maintenance is eating into meaningful work. My guess would be that we engineers are not great at estimating the time it actually takes to deprecate something. Replicating some legacy functionality in a new service and migrating feature X onto it may take only 6 months to pull off, so when it comes time to estimate the project that's exactly what we say. However, migrating the rest of the codebase to the new stuff is far from trivial and on its own would take another 6 months. Where's the value though? Often there's no obvious "value" play; only the promise of spending less time on the old stuff in the future, of a possibly reduced infrastructure bill, and so on; no net-new dollars.
I think it starts with being more honest about our estimations. Realizing that the full build + deprecation is going to take a whole year vs. 6 months for the full build and only "essential" migration does not mean that the full deprecation is a non-starter and should not be discussed. It's just information, and how we shape it is up to us. Start asking questions about it, and think about how the project could be spun into different pieces. Consider the consequences of taking the easy way out - what will your future maintenance burden be if you can only deprecate 80% of the old functionality? How about 60%? What projects are coming up that the remaining pieces could feasibly get rolled into? Willfully ignoring the true effort required isn't going to make it take less time; if anything, it will only get worse. You'll be forced to recon with this fact again as you approach the deadline set by your overly optimistic estimation, many months away from the discussions and information gathered during the estimation phase.