And I’ve been there more than once. You land in a new role, full of energy. New organisation, new mission. There’s already a solution in place, built by someone else. No documentation. No onboarding. You’re lucky, business owners are very supportive and excited to have you on board. What about the engineers handing over? Unfortunately, sometimes they see you as a threat and more often than not their inner child takes over, and they turn into gate keepers for information at every step.
So, you breathe deeply, stay calm, and start juggling the hats: auditor, handyman, strategist. Behind the curtain, you’re mapping the pros and cons, calculating the costs of building on top of tech debt versus starting fresh. Meanwhile, you deliver new features, patching the system here and there, keeping the boiling pot under control.
But soon reality hits: your clean, modular approaches are nothing against the clutter of a bigger mess, and keep colliding with an ocean of outdated data structures, fragile backends, spaghetti frontends, and countless third-party dependencies. The system drags your effectiveness down.
That’s when the moment of choice comes:
- To patch forever and let the system collapse and costs explode eventually.
- Or to face the debt, early enough, and rebuild NOW.
I’ve chosen the second path several times. I’m not famous for taking short cuts. It’s not always easy. You pitch the refactor like a salesperson, convincing peers and stakeholders. You plan. You document. You tear down piece by piece and build it back stronger: infrastructure, databases, architecture, frontend, even design details. You trust your intuition. And slowly, the system transforms.
In the end, you don’t just own the code. You deliver back the ownership of the process. The trust. The documentation. The experience. And most importantly, you nurture the belief in the organisation’s ability to innovate.
Because rewriting software and rethinking systems is not a failure. Rewiring is also where design thinking meets engineering, and where strategy becomes systems thinking and architecture.
Some takeaways for anyone facing a mountain of Over(or under)-Engineered Tech Debt and are unsure whether to refactor and more over convince others that YOU NEED TO:
- Diagnose: Map the pain points clearly → architecture flaws, DB bottlenecks, infrastructure issues, third-party dependencies. What are the real requirements, and what’s currently unsolved? What is costly and underdelivering? What is definitely broken and why? What is following best practices and official documentations and what went away from it?
- Quantify: Put a price tag on inaction. Hours lost, infrastructure costs, team velocity dragged down. Compare it with what you’ll gain by fixing and wrap it in a small chart.
- Strategize: Define your strategic horizon. Timeline, steps, dependencies, mitigation. Build a realistic but brave plan, on how you will mitigate disruption, how your simplification will solve and add value to each of the problems you diagnosed.
- Pitch it: Sell it honestly. Focus on benefits, not on blame. Speak to value, not ego.
- Execute: Move steady and calm. This isn’t a sprint. Refactoring is an ultra-marathon or a vipassana retreat (haven’t done the former one, but that’s how hard I imagine an ultra to be).
- Document: Every step, every win. Write down the progress with hard numbers: faster queries in orders of magnitude (e.g. 2000ms -> 20ms) , cleaner workflows, leaner CI/CD pipelines, reduced Infra Costs, improved response speed, reduced roundtrips between the client, the server, the DB, the authentication layers, the ML endpoints. This will help your team know when you’re done and keep your aims at sight.
- Deliver: Watch the seeds of simplification grow. Celebrate the compounding effect of clean systems and enjoy the new road ahead.
These are the steps that I follow and I hope they will help you too, to be ready to continue JUST-Engineering. Because, JUST is when you use the right amount of effort and resources that match the requirements and delivers the compounded value your organization hired you for.
Last, don’t forget humility in the process, even when things get nasty. Forgive others’ first attempts, because no one writes bad code or designs suboptimal architectures on purpose. Share, learn, teach, improve.
I’ve been through this cycle several times. Every time I have learned a bit more than the last. About engineering, about people, about myself. Every time I came out calmer. And I’ve grown to enjoy the process, because it proves something fundamental:
Systems can always be rewritten and thought otherwise. And when they are, the road ahead is ever new.
Have you been there? Are you there right now? Do you know anyone in this situation? If yes , then feel free to comment, share your experience, or share it with someone you think will find this empowering and help them in their decision making to start rewriting now.
Originally published on Medium.