Here’s a funny thing about positive framing and how long-lasting its impact can be. To a lot of folks in tech, the phrase “legacy code” at best conjures up “old and crusty” and at worst “kill it with fire”. If you’re a developer, you may see working on it as a “necessary evil” or “what pays the bills”, but the prospect doesn’t make you jump out of bed with a smile. And I get it. I’ve worked with enough engineers over the years to understand this firsthand.
But for me, legacy code has a certain warm and hopeful association that I just can’t shake. It’s because my earliest exposure to the challenges of legacy code was through an engineering book club I joined at my first dev job. We worked through Michael Feathers’ book “Working Effectively with Legacy Code”. While my EM organized the group, he led very collaboratively. He had an engaging, inclusive leadership style that encouraged others to talk openly about the challenges in our own 10 year old codebase and how we might remediate them. Far from a gripe sesh, the electric exchange of experiences and ideas was so energizing! I may have been one of the most junior devs in the room, but I felt like I belonged. While we talked about hard problems, nothing felt insurmountable.
I remembered this feeling when I recently led a session for The Lead Dev on how enterprises can overcome the challenges of legacy code, and again when I read Marianne Bellotti’s “Kill It with Fire”. All three experiences convince me that a crucial part of working effectively with legacy code, especially as a leader, is how we communicate about it – and how we paint and foster a vision of what’s possible. As Bellotti says, “communication is an essential part of keeping modernization on track.” Communicating the plan, goal, and constraints in a warm, inspiring, and inclusive way is key to helping others feel up for any challenge.
If you’re a manager looking for practical tips or strategies for effectively communicating about legacy code in your context, consider these:
- On the team: Create a space where developers at different points in their career can come together openly discuss challenges and opportunities in your current architecture. What might work well in your context?
- For all of engineering: Prioritize documentation. What parts of your legacy system are opaque, hidden, poorly documented, or where the knowledge is locked up in 1-2 individuals? Could you prioritize time this quarter to finally get it written down?
- Working 1:1: Build trust directly. When your ask your engineers in 1:1s how they really feel about the current challenges and opportunities, do they answer descriptively and with detail, or not? The lack of a real answer (or the fact that you’re not even asking) indicates that you have work to be done building trust.
Leading with Spoons 