🚀 Join the ATDD Accelerator waitlist
👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.
“It’s NOT working!”
Dev: 𝘲𝘶𝘪𝘤𝘬 𝘧𝘪𝘹
“It’s broken AGAIN!”
Dev: 𝘢𝘯𝘰𝘵𝘩𝘦𝘳 𝘲𝘶𝘪𝘤𝘬 𝘧𝘪𝘹
And so the cycle continues…
Quick fixes feel fast, but they pile up technical debt.
The cost? Bugs resurface, systems become fragile, and development slows to a crawl.
The real fix? Invest in proper testing, refactoring, and root-cause analysis.
Short-term speed without long-term stability is just a trap.
Duplicated Validation Logic backfires
Developer copies the same validation logic for user input across multiple services.
Later, a requirement changes - like email format validation.
Now every copy must be updated individually. Miss one, and suddenly some parts of the system break while others work, causing unpredictable bugs and slowing down future development.
Copy-Paste SQL risk
Developer quickly writes a database query in one module, then copies it to another module without abstracting it.
Later, the database schema changes.
Each duplicated query needs manual updates. Missing one leads to runtime errors in production.
UI: change once, fix everywhere
A UI component is copy-pasted across different screens to save time.
A minor style or behavior change is needed later.
Because it’s duplicated, updating every instance is tedious, error-prone, and inconsistent.
Inconsistent Logs, Frustrated Devs
Logging or error-handling code is duplicated across microservices to speed up delivery.
Later, you need to standardize logs for monitoring.
Updating each copy individually takes hours and risks missing some, making debugging harder.
Quick fixes now create slowdowns later.
Problem: Teams take shortcuts to deliver quickly, but the messy code accumulates and slows future work.
What happened: Copy-pasted code spreads bugs or makes the system hard to change without breaking things.
Solution: Invest in small, incremental improvements - refactor duplicated code, add tests, and build maintainable patterns. It slows you down a little now, but prevents hours of frustration later.
Urgent bug fixes vs. refactoring
Firstly introduce Acceptance Tests (with no refactoring) so that we have protection that we don’t introduce User-facing regression bugs.
Then add lower-level tests (Component Tests, Unit Tests…).
Then start refactoring.
Allocate a small portion of time to it initially. Over time incrementally increase test coverage & refactoring. That way, it’s easier to get management buy-in.
🚀 Join the ATDD Accelerator waitlist
Quick fixes are like duct tape - great for the day, terrible for the year. But how should you refactor a big legacy codebase without breaking production?
One thing that has helped some of my team was to divide the bug tracking process in three:
- initial bug investigation, to know what's going on
- initial fix, to fix the problem
- final fix, which includes refactoring so the problem is less likely to happen in the future
The trick here is to not consider the big fix until all three steps are done. That's also required to consider bugs as top priorities over features.
Similarly, I consider individual refactoring tasks as ill-conceived. Refactoring should always be part of the delivery of a feature. Putting them aside make them optional, and so easier to skip. One should even consider doing them before working on the feature itself.
In the above, it's also important that the team is able to deliver in very small chunks. Each delivery should be taking less than a few days, ideally no more than a day of work. It takes times for team to be able to achieve that, but such a constraint is probably the strongest incentive to create a maintainable architecture.