Hard arguments around legacy support
Even hardened hearts with years of ‘build vs buy’ debates under their belts will flee the weighty footsteps of approaching ‘rebuild vs maintain’.
Having seen a few of these now, I can comment on some patterns – which fights are worth fighting and where things go off the rails.
Justifications
‘v2’ is an exciting label on what is essentially treading water – expending metabolic energy to stay stationary. In water rescue, treading water keeps you warm and breathing while you await rescue (it was also a requirement for me to graduate college).
We make the decision to build v2 for a lot of reasons, some of them political some of them technical.
Politics: v2 can be a case of technology leadership following political power rather than the more-sensible reverse configuration. This can happen when manager A wants to defang manager B, or when a senior manager loses trust in the existing project owner and wants them replaced. It can also be a new management hire wanting to make a splash and using their ‘ear of power’ to lobby for the assignment.
Technology: This can mean a lot of things. Switching languages, frameworks, libraries, vendors, hosts. Standardizing N ways to 1 way. Adding or removing client support.
‘Improved tooling’ is a weird justification for a rebuild because this class of improvement is often compatible with legacy codebases.
Faster builds, faster / better tests (whether by improving fixtures or automating manual steps), better linting, simplified build graph, better CI / deployment – these are all discrete and easily planned-out goals that can be (1) carried out in a legacy codebase and (2) makes it easier to design / break up any subsequent full rewrite.
Easier, though perhaps less justifiable, as the legacy system is now healthier. This last point, that investments in the health of the legacy system reduce the demand for the rewrite, may explain why v2 owners often try to bite off large chunks and resist pressure to deliver a slim MVP.
Total staleness: As a believer in systems and senescence this is both my favorite justifciation (as it taps a philosophical belief) and my least favorite (it feels like it should be avoidable). But if you’ve owned any old piece of machinery (old car, old laptop, old house, knee & hip joints) you’ve hit the point where the thing is more expensive to maintain as your daily driver than to replace. Sometimes it’s just time.
Don’t let late v2 clog the drain
The v2 owner will argue hard for v2 to be the default – in your ops, in your codebase, everywhere. But, usually, v2 will be late.
The story goes something like:
- Legacy will work less well as v2 begins implementation and starts to break things (dependencies, docs, defaults; schedules, sanity, souls).
- v2 will weaponize legacy’s feature backlog. v2 will clamor for them to be implemented on v2 and also against building them on legacy (despite justifying v2 by the fact that these features are missing from legacy). The v2 owner will fight against maintenance work on legacy even when it’s a clear win.
- v2 will lobby other teams to build their features on v2 using promises (we’re almost ready to deliver) and threats (if you build this on legacy it (a) won’t work and (b) willl break everything)
- Which means when v2 is invariably late, the org will be in a solomonic position of having to decide which things to rewrite on top of legacy – a technology they’ve spent many months & non-indoor voices convincing themselves is the cause of all their ills
Like most narrow passageways to get out of this one you’ll have to lose some skin. Assign an incident commander as if this is an emergency (because it is). Put the legacy and v2 owners in a room and keeping them there until they have a detailed plan. Then, interrogation-style, split them up and grill each one over it in private. Force them to justify every line item, delete the half that don’t make sense, and go.
How do you avoid getting into this situation
Don’t predicate future things on v2 until neutral third parties think it’s ready; don’t let the v2 owner make that call. Never predicate future work on delivery of overdue current work.
Make v2 as small as possible. If it can have a smaller footprint than v1, fine. If it can reuse most parts, fine.
Managers will want to make v2 bigger so they can solve all the perceived problems at once, but: v2 mgrs don’t understand the problems as well as v1, and are so incentivized not to admit this that they can’t even know it. v2 mgrs sometimes but not always understand certain core pieces of the problem better than v1 maintainers.
Advice to legacy & v2 maintainers: once the die is cast, stop fighting and cultivate an honest, private dialogue. Also cultivate other job offers because there’s no telling how the chips will fall and the rest of the company will blame both of you.
Pay down tech debt constantly, without asking permission, or you’ll pay the iron price for it later.
