Legacy System Mindset
Note: This is a rework of the forward I wrote for the book “Brownfield Application Development in .NET.” No one reads forwards, so I thought I might republish here. I made a few, minor edits to help it stand on its own.
It takes a certain mindset, maybe brand of will, to succeed in wrangling out of control systems. I’m a strong believer in putting values and principles first in the selections of practices, techniques, and tools. Sticking to a core set of values helps us gain ground whole working in tricky, gnarly systems.
Three values help when dealing with legacy systems: passion, patience, and collaboration. There are others, but these three give have given me solid ground when detangling and delivering a legacy system.
Passion drives the best developers to find and master new tools that work, an act which inspires those around them to embark on the same journey. Engineers who have a passion for crafting elegant, maintainable solutions for well defined problems and a drive for learning new techniques to do so are the real ninjas. The myth of the 10x unicorn developer is an insult to the hard hours many of us put into inquiry, practice, and action to advance our craft.
Working with legacy systems requires a particular kind of passion. Situational passion. Legacy systems tend to be chock-full of cleverness, mystery, and fatiguing, mind-bending problems. It helps if you don’t mind getting your hands dirty. It helps if you have the courage to throw yourself headlong into the mess. It helps if you’re motivated by reducing entropy over time. It helps if you can lead your mates through examples. These examples illustrate the particular brand of passion suited to this type of work.
Technical debt is a drag in more ways than one. Literally, enough debt will clog throughput of business value delivery, slowing time to market. Figuratively, unruly code chips away at an individual contributor’s willingness to live, participate, and engage in your product community. In agile manifesto terms, it jacks up sustainability.
Does anyone enjoy showing up to work and treading water for days, weeks, or months on end? Sometimes a section of code can seem so daunting, an attempt at modifying its behavior so hopeless, yet a rewrite/reboot is impossible because even though the system is legacy it is in someway important and successful to its owner, operator, and customers. Never mind more nefarious obstacles beyond our control: politics, vendor lock-in, short-term myopia, sunk cost fallacy, etc.
Technical debt is a drag in more ways than one. Literally, enough debt will clog throughput of business value delivery, slowing time to market. Figuratively, unruly code chips away at an individual contributor’s willingness to live, participate, and engage in your product community. In agile manifesto terms, it jacks up sustainability.
As a developer and maker, working in a larger ecosystem, there are likely forces beyond your control. Slim chance your product development financier will readily part with funds needed to “ensure you get it right this time.” Sometimes you’ll find yourself thrown into a brownfield system that’s supporting a successful revenue stream. The system, too big and important to fail, has less of a roadmap and more of an event horizon. It is here to stay because money.
Don’t despair! Steel yourself, summon and practice patience. Look for areas where you can make improvements, small and, eventually, large. You might have to be patient with your sponsors. Build influence through lucid arguments and results. Delivering on what you say you’ll deliver starts you on the path to a trust relationship, and more trust grants permission to make more ambitious, systemic changes. Small to large. Patience.
It‘ll take time. Patience! This is fine. While you’re practicing patience, learning, and pragmatism you‘ll slake your thirst and ambition and slow your first impressions which may damage influence. Repeat this manta, “good leaders demonstrate a good attitude.” Keep morale steady, especially when the going gets rough.
Getting people all aboard the improvement train is key. It’s everything. Collaborate with your customers and fellow developers, testers, product managers, designers, and others to succeed a sustainable, methodical turnaround.
Leadership, I keep finding, has very little to do with a role, title, or position, and everything to do with who steps up in a given situation.
Your sponsors should understand the long-term benefits of large scale refactoring, restructuring, or even rewrites. When you bring such a proposal to the table, you’re bringing it to a negotiating table. Help your sponsors understand the value of investing in quality — “what’s in it for me?” Make your case with supporting data, in terms non-technical folks can understand. Don’t ambush, share. In my experience true collaboration builds as a snowball effect. It only takes one leader on the team to get it rolling, and that might as well be you. Leadership, I keep finding, has very little to do with a role, title, or position, and everything to do with who steps up in a given situation.
I spent the first half of my career creating software intensive products from the ground up, involved from inception through to deployment. I was exclusively a greenfield app guy. When I entered a product community that had real technical debt, it was a harsh transition.
Most of my frustrations stemmed from my inability to invite a collaboration, my own impatience, and misaligned passion for a set of practices inappropriate for puzzling through confusing code. It took a few interventions from peers, people I consider situational leaders, to get my mind around the fact that my attitude was holding me back. Once I listened to that feedback, took it, and started working toward changing my mindset, I found my efficacy improved greatly.
