Optimise for a Strong Legacy, not Friction
Not all Legacy Code is Tech Debt
Make your Legacy Code be a Monument, not a Museum
There are relics from ancient times strewn about Europe that have been turned into Museums. Picturesque relics of an unknown complexity where the details vanished and the only thing that survived the test of time were the infrastructure layers.
However, some places like Dubrovnik embrace the legacy they were given: Halls, temples, churches and marketplaces are still being used to date for the same purpose as originally: to serve a group of people with a particular function. With quite a bit more tourists mind you, but still - there is no sterile isolation and artificial anti-corruption brokerage like one would find in a read-only Museum.
Some Teams Churn out “Museums”
Microservices seem to be a fashionable trend to partially address this issue by fragmenting the team to work on small enough units so they become unable to produce a legacy monstrosity.
This isn’t always successful however as we’ve seen with Amazon’s Prime Video recently. Unless consciously targeted, large legacy modules inside a companies inherited codebase will continue to attract attention, bugfixes and features opposed to leaving space for investment into greener pastures.
This in itself is an anti-pattern that further demotivates an already disgruntled team.
Developers leave companies for two reasons:
Having a bad relationships with their manager
Being subject to constant friction and stress due to their old codebase without relief in sight
Weathering an environment where both pain points above are a constant quality within the team culture invites a level of cynicism that makes the propagation of it mandatory even to optimistic newcomers to the team.
This is a self-imposed limitation that will ensure continued struggle.
Strangler Fig: A Popular Solution to Developer Friction and Churn
I have recently demonstrated an example of approaching modernising a legacy PHP system with a recent client.
This could be a chosen database, a past end-of-life server dependency like old PHP or C# versions or simply a way of work — a diet of bad habits that is difficult to shake for an old team.
The premise is simple: to make a large leap in dependency upgrades or way of work, first you need to stop investing into the old problem.
Those of you that follow Domain-Driven Design will know of the anti-corruption layer. This used to be a hard sell, but nowadays there are many technologically approachable solutions:
Dockerize the new server and build all new features in it, proxying old calls in parallel to the old system for verification and parallel migration
Capture use cases to the old system with a modern facade lets messages through, but picks up new functionality through DB-specific Change Data Capture tools like Debezium or Event Streaming
Tidy First: an aptly named title for Kent Beck’s new newsletter and book, invest into a process that has the team improve their immediate environment before they start working on a feature. The best chefs clean their kitchen before they start cooking, not just after.