This article was written by Henn Ruukel,
Principal Group Engineering Manager for the IC3 Fraud Prevention Team at Microsoft.
If you currently own or are about to build a technical system, you will also need to figure out the "why," "how," and "what" about that system's legacy. In this article, I would like to share my perspective on this topic, which I have gathered based on modernization efforts in my team here at Microsoft.
We have a 15+ year history of building spam and fraud
detection systems using various technologies. This has led us to a significant
variety in our tech stack, which we have systematically cleaned up over the
past few years (and are still working on). Hopefully, this helps you in your
journey!
What is legacy?
One way to define legacy is that anything you build becomes your legacy once it is born. From that moment onward:
· it requires effort and maintenance to keep working;
· it both limits and empowers your potential for future developments;
·
your team's
skills and knowledge must include capabilities to maintain and modify it as
long as it exists.
This definition doesn't only apply to the code you create. It also extends to business logic/functionality, architectural choices you make, and the infrastructure you choose to use. All components and layers of your system are part of your legacy.
So, if you agree with this definition, you cannot
avoid creating legacy. Therefore, it's better to accept its existence and
incorporate elements into your planning process that constantly review
opportunities to invest in legacy cleanup.
Why should you invest in legacy cleanup?
Each system and team probably has its own reasons and motivations, but here are a few common ones:
External Dependencies and End-of-Life: When a technology or library provided by an external party is being deprecated, you usually receive ample notice to migrate or upgrade. This is a straightforward case with clear external motivation and deadlines.
Technological Entropy: As your team and its portfolio of different systems grow older, you're more likely to face technological entropy. Different systems built at different times by different people naturally create variety in architectural approaches and tech stack decisions. While technical variety can make sense, consider consolidating technologies, when possible, to save costs and improve engineering efficiency.
Team Intellectual Ownership Risk: It's essential to avoid situations where only a few people in the team can maintain and modify a particular system. This situation can create dependencies and dissatisfaction. Investing in this context involves freeing up these individuals and enabling the wider team to own the system again.
New Technology Opportunities: Occasionally, the team may be tempted to try out new
technologies. Invest in these opportunities while ensuring a clear commitment
and decision-making process for adopting new tech.
How to manage legacy cleanup (in parallel with product development)?
Assuming you and your stakeholders agree that investment is worthwhile, here's how to make it happen in parallel with your regular product development, where the backlog usually contains more new work than your team can deliver.
Continuous Investment: Treat legacy cleanup as an ongoing process, similar to a monthly payment. This approach prevents situations where you need to halt all new work for several months to address legacy issues that have accumulated.
Scope Management: Avoid mixing cleanup with system logic improvements. While it might be tempting to revise business logic during migration to new technology, this can expand the scope and time spent on migration.
Short Iterations: Keep the scope of migration clear and small. Think of migration as jumping from one ship to another. Avoid spending months in a state where parts of the system have migrated while others haven't. Measure progress in calendar time, not developer hours.
Dedicated Isolated Mission Team: Depending on your team's size and capabilities,
consider creating a dedicated project team focused solely on migration,
especially for multi-month projects. Alternatively, manage migration projects
within the team, treating them like any other backlog work if the scope is
clear and small.
In summary, legacy is continually created, so invest
in managing it openly and transparently within your planning cycles. I hope
these thoughts help, and good luck!