Today’s episode is about persistence, patience, and the power of Test-Driven Development (TDD).
At this client in the US, where I’ve got the chance to work for almost one year, their code base had grown almost exponentially, with millions of lines of code, thousands of components tangled in tightly coupled dependencies, outdated logic, and patches on top of patches. Refactoring a small bit of this legacy required 100x reading and re-reading to try to understand what was going on.
We knew the risks: change something to improve one area but break everything else around. But we also knew that if we didn’t do anything, the system would just keep on growing and growing and the client would be unsatisfied with our services.
Building Confidence One Test at a Time
Instead of diving in headfirst or rewriting everything at once, we committed to a disciplined TDD approach. Every new feature, bug fix, or refactor religiously started with writing failing tests that defined the expected behavior. Then writing code to pass those tests. Slowly, test coverage grew, covering critical paths, edge cases, and legacy components along the way.
A Year of Incremental Progress
Refactoring and removal wasn’t a single task. Over twelve months, each component we tackled was first surrounded with solid tests. Then we refactored, improved design, and when possible, removed obsolete code.
We kept meticulous track of coverage, code quality metrics and deployment stability. Each successful removal was a step towards a leaner, more maintainable codebase.
Safer, Cleaner, Faster
After a year or so, we removed a significant chunk of legacy components without any major incidents. Our Continuous Integration pipeline was waaaaay faster, debugging was less painful, and developers were less fearful of introducing regressions.
More interesting than that, the culture shifted among the client developers. TDD wasn’t just a technique people heard about it before; it was a discipline translating into confidence, clarity, and collaboration.
How did we get the client developers to learn TDD? As part of the discipline of introducing TDD, we introduced pair programming as well. We didn’t have a budget for training so the best way to teach the client developers was by showing them how to do it. No test or code was written without having two developers (mixing client and from my consulting company), sometimes using a driver-navigator approach, sometimes using a “one writes test first and the other writes the code to make that test pass”.
Key Insights
TDD is a powerful ally against legacy code but it requires patience and discipline.
Incremental progress beats big rewrites every single time.
Metrics matter: track coverage, code quality, and stability to build confidence.
Pair-programming helps with teaching, real-time code review and better solutions (two brains think better than one)
