Every so often, a software development project lands on your desk with the shape already decided. The old system is the villain. It’s written in something nobody wants to touch, it breaks in ways no one can explain, and everyone agrees the answer is to rewrite it on a modern stack, run the project the right way this time, and finally be rid of it.
The Rewrite Won’t Save You.
It’s a satisfying story, and it feels like the responsible thing to do. Nobody ever got in trouble for wanting to retire a decades-old codebase.
Teams do exactly this all the time and still fail. They get budget, they get a modern framework, they run their standups and their retros, and a year later they’ve spent a fortune to produce a shiny new system that nobody is actually happier with. If the old technology were the problem, replacing it would fix things. It often doesn’t. So before you write a single line of the replacement: if it isn’t the code, and it isn’t the methodology, what is it?
Here’s What Actually Sinks Software Projects.
The common thread in the modernization efforts I’ve watched go sideways isn’t language, framework, or how faithfully the team followed a process. It’s communication. It’s the quiet breakdown between the people building the software and everyone else who has a stake in it. The vision drifts. Assumptions go unspoken. The people who actually use the thing every day never get asked what they need. By the time that surfaces, it surfaces as a schedule slip or a budget overrun, and everyone reaches for the nearest technical explanation.
This isn’t just my read. In its Extreme CHAOS report, the Standish Group distilled years of research into why software projects succeed or fail down to ten success factors. Most of the top ones have nothing to do with engineering. Executive support. User involvement. Clear business objectives. Firm basic requirements. More than half the list is about people and alignment, not about the stack. That points at two levers worth more than any rewrite: a genuinely shared vision of what the project is for, and trust between the people involved. They aren’t independent, either. You build a little trust, which earns you a more honest conversation about the vision, which builds more trust. Start one and the other follows. Neglect both and no framework will save you.
Shared Vision: The System Nobody Documented.
A while back, a team I know was brought in to replace an aging records system. It was written in a language that predates most of the people maintaining it. The client was ready to spend real money to rebuild what the software did, feature for feature. The brief was essentially, “Make this same thing, but modern.”
Before committing to that, the team watched people actually use the system. That’s where the project quietly changed. The real system, it turned out, wasn’t the software at all. It lived in the head of one long-tenured specialist (let’s call her Jane). Jane kept the whole operation running for years on a scaffolding of undocumented workarounds only she understood. How much rode on Jane? Her job included processing rebates the co-op owed its members. The summer she took an extended vacation, she came back to more than $13 million in unpaid rebates piled up in accounts payable, waiting on the only person who knew how to process them. And Jane was a few years from retiring.
Here’s the part that reframed the whole engagement: the client was only really using a fraction of what the old software could do. Rebuilding it feature-for-feature would have faithfully reproduced a system nobody needed while doing nothing about the real risk of all that knowledge walking out the door. The only reason anyone learned this was that the team made the invisible visible. They didn’t just read the spec; they observed the work and mapped how it flowed, on paper, where everyone could stand around it and point. A shared vision means agreeing on what a project is genuinely for, and you rarely get there from the conference room. You get there by including the people who live inside the system every day.
Trust Is Built in Small Increments.
Shared vision gets you pointed in the right direction. Trust is what lets you keep moving when the road gets rough. On a different project, a standalone desktop application attached to a medical device, the client had every reason to be skeptical. The problem was messy, the outcome was uncertain, and promising a big, confident result on some distant date would have been an easy thing to say in sales and an easy thing to disbelieve in delivery.
So the team changed two things: how it described the work, and how it made the plan visible. Instead of framing work as an internal engineering activity (e.g., “refactor the device communication layer”), the team described each piece as an observable outcome, a specific capability the client could watch working. The team managed the plan visually too. They sized every piece by the effort it would take, so the tradeoffs were legible to the people paying for it. When the client asked for something new, they could see exactly what it pushed out, because both pieces were sized and sitting on the same wall. Visibility was the part that mattered most. What was on the plan and what was falling off it stayed plainly visible. No hiding the misses inside a status-green slide.
Trust accumulated not because anyone asked for it, but because the client watched small, concrete promises get kept, iteration after iteration, until the pattern became believable. That’s what trust actually is on a software project. It’s not a personality trait or a handshake at kickoff, but the compounding interest on a lot of small, kept commitments. It’s what buys you the credibility to eventually say “the scary part is next, and you can believe us when we tell you how it’s going.”
When You Can’t Just Say “Trust Me”
The hard case is when the problem itself is invisible, or so strange the client struggles to believe it’s real. During a mobile project with an inherited codebase, the headline complaint was a bug that showed up intermittently. Sometimes it worked, sometimes it didn’t, and no one could reliably make it happen on command. An un-reproducible problem is a technical team’s worst nightmare, and it’s an almost impossible thing to explain to a non-technical stakeholder who just wants to know why it isn’t fixed yet.
The move that broke the logjam wasn’t to code faster or work later. It was to draw a picture. The team used a simple cause-and-effect diagram to lay out every possible contributor to the failure. The phone types, the network conditions, the edge cases in the backend. Suddenly a client who couldn’t read the codebase could read that. They could see it wasn’t one bug but a whole family of them, symptoms of a deeper design problem, and they could reason about it alongside the team instead of just waiting on them.
That’s the same instinct from the discovery story, pointed at a different problem: shared vision and trust are both built by making things visible to the people who can’t otherwise see them. When alignment breaks down, drawing the picture usually beats writing more code. It’s what finally gets everyone seeing the same thing.
Ask a Better Question
When a legacy system is grinding your organization down, and the instinct is to ask, “How do we modernize this code?” try trading that question for two better ones. Do we actually share a vision of what this project is for with everyone who touches it, not just the people building it? And have we earned enough trust to be believed when the work gets hard?
Answer those honestly and the technical path usually gets a lot clearer. Sometimes clear enough that the big rewrite turns out not to be the thing you needed at all. The best modernization work I’ve seen is mostly communication work wearing an engineering costume, and the teams that understand that ship what people actually needed. The ones that don’t just ship a newer system nobody is happier with.