Empathy in Code Modernization by Julian Flaks
When engineers and architects encounter unfortunate legacy code situations, they can have strong emotional reactions. Patterns of development have changed over the years, and codebases can easily degenerate over time as needs change or hurried alterations become necessary. For the present day developer, legacy code is often only experienced as a thorn in the side, and the effort and sense of achievement behind it is overlooked. It's easy to slip into negative opinions around the wisdom or even motivation of the original implementers. It seems something of an industry in-joke to acknowledge how much disdain or blame our own current decisions may incur later on when taken out of context.
The truth is that while we need to make value judgements about the code we see, it is very helpful to empathize with the teams who created the code and to appreciate the culture that lay behind it. Knowing that things were done to prioritize speed of result over extensibility, for example, can give you clues to look out for copy and paste code or long missed refactors of methods. Realizing a specific design was being followed that added complexity can help steer your eyes to what gains were achieved and what design difficulties may await a refactor of the same problem.
Above all, understanding that the team probably did the best they could in the time they had lets the modern developer move on and treat the code as a problem or partial solution rather than perceiving an ideological conflict between themselves and past developers. If a whiteboard was capable of time travel, and we could collaborate with former teams, we would find our approaches and opinions closer than we guess.
There is a flip side to this, where empathy must be tempered with skepticism. The mere fact that a pattern or approach existed in the past does nothing to prove that it is still valid or applicable in the present day. Adopting a same-again pattern may seem the safest approach, but absent clear documentation, architecture (and ideally test code), it is a glib assumption to believe a legacy solution represents correctness or reliability. Reapplying an existing approach may be completely valid, but the present day practitioner takes the same responsibility for it as for an entirely fresh solution.
Of course, that trust in others’ efforts and open minded evaluation of results is really just a matter of regarding legacy teams and code with the same consideration that is embodied in good retrospectives and egoless development mindsets.
Where empathy should end is in code itself. Intricate solutions that were someone's pride and joy only exist to serve a purpose. If a codebase can be made redundant and deleted by something simpler, doing so is probably a good thing. Doing so is not a slur on what was made before or the purpose it once served. Codebases weigh heavily upon development teams like emotional baggage. The more these things can be let go, the more time and energy everyone has for future endeavors, and for tackling the work that holds the highest business value.