Over-engineering sucks, and it is easy to spot in the work of others. Harder to see it in yourself. 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 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 gatekeepers 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 shortcuts. 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-engineered, or under-engineered, tech debt and unsure whether to refactor, and how to convince others that you need to:
- Diagnose. Map the pain points clearly: architecture flaws, database 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 follows best practices and official documentation, 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 horizon. Timeline, steps, dependencies, mitigation. Build a realistic but brave plan for how you will limit disruption, and how simplification will add value to each problem 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.
- Document. Every step, every win. Write down the progress with hard numbers: faster queries in orders of magnitude, cleaner workflows, leaner pipelines, reduced infrastructure costs, fewer roundtrips between the client, the server, the database, the authentication layers, and the model endpoints.
- Deliver. Watch the seeds of simplification grow. Celebrate the compounding effect of clean systems.
These are the steps that I follow. JUST-engineering is when you use the right amount of effort and resources that match the requirements and deliver 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. Systems can always be rewritten and thought otherwise. And when they are, the road ahead is ever new.
Originally published on LinkedIn. The related Medium essay is Over-engineering sucks, and it is easy to spot in the work of others.