Legacy System Mindset

Dave Laribee
Jul 10, 2017 · 5 min read

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.

Improvement takes time — Patience + Passion.

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.

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.

Collaborating for more parsecs!

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.

The Nerd/Noir POV

Thoughts on product development, team-building…

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store