Beyond the Debug: Burak Özdemir’s Take on Sustainable Technical Debt Solutions
In the fast-paced world of software development, technical debt can quietly pile up, until it starts to block progress altogether. From slowing down releases to draining developer morale, it’s a silent productivity killer. But as teams scale and systems age, finding smart technical debt solutions isn’t just helpful, it’s mission critical.
But how do you really handle it day-to-day? How do you convince leadership it’s worth fixing, and how do you keep your team motivated to tackle something so… unglamorous?
To get to the heart of these questions, we talked with Burak Özdemir, founder of Morse Code Translator. Burak’s got plenty of real-world wisdom on technical debt, leadership dynamics, and the balancing act every startup faces.
The interview explores what he had to say in a candid chat about all things’ technical debt—solutions, how he defines it, prioritizes it, and the one simple habit that can save your team from drowning in it.
Q: How do you define technical debt, and what guides your team’s approach to tackling it?
Burak: I define technical debt as any shortcut or trade-off that creates extra work in the future. I group it into three types: rushed decisions during delivery, outdated tools or libraries, and unclear or duplicate logic. To prioritize, I look at technical debt solutions, how often a piece of code breaks, how much it slows us down, and how risky it is to change. If something is slowing releases or blocking new features, it moves to the top.
Q: How often do you see the higher-ups, maybe even the CEO, brush off fixing debt because they want to chase the next shiny thing? How do you deal with that kind of pressure?
Burak: Oh, it happens all the time, especially in startups. The pressure to ship new things can push tech debt down the list. I handle it by showing how unresolved issues cost more time later. I keep a log of repetitive work caused by debt and use that to build a case for fixing it. Numbers speak louder than long explanations.
Q: There’s a common saying: you can’t fix everything in legacy systems. Do you see that as a reality or just an easy excuse?
Burak: It’s a real constraint. Some systems run on fragile code that nobody wants to touch unless it breaks. Calling it a cop-out misses the fact that teams have limited time and focus. The smart move is to fix what blocks your progress and leave the rest until it becomes urgent.
Q: Have you ever felt like trying to chip away at technical debt actually ends up slowing your team down or hurting morale? How do you keep that balance, so folks don’t get burned out?
Burak: Yes, teams lose steam when every sprint includes clean-up tasks and not enough visible progress. I set a rule: no more than 20% of a sprint on technical debt unless there’s an urgent fix. We rotate those tasks across the team, so no one feels stuck with all the boring work.
Q. Are there any non-traditional methods you’ve personally employed to manage debt that others might frown upon? What were the results, and would you recommend them?
I once ran a “debt freeze,” where we banned adding any new features for two weeks and only cleaned up code. Some thought it was wasteful, but the outcome was faster development in the months after. I’d do it again, but only with a team that understands the purpose.
Q. Some folks worry that obsessing over tech debt leads to endless rewriting and refactoring cycles, which slows down delivering real value. Do you think there’s a point where you’re just chasing your tail?
Burak: Absolutely. After a point, refactoring becomes a comfort zone. I’ve seen developers polish the same module while customers waited for improvements. I keep a running list of what’s actually slowing us down and ignore the rest unless it breaks. Not every cleanup brings real value.
Q: Looking at your past experience, what’s your worst mistake in reducing technical debt, and what did you learn from it?
Burak: I once rewrote a working module to apply a new framework I liked. It broke other parts of the system, and we lost two weeks fixing what didn’t need fixing in the first place. Lesson learned: don’t fix what isn’t broken unless you have a real reason.
Q. Are there any simple or underrated tools or metrics you rely on? Something people might overlook.
Burak: I use git commit logs and issue tracker tags to trace how often we patch the duplicate files. It’s simple but shows patterns. Code churn reports also help spot unstable modules. These aren’t fancy tools, but they highlight where effort is wasted.
Q: If you had to pick just one thing to change or add to how a team handles technical debt solutions, what would that be?
Burak: Build review time into planning. Even just 30 minutes a week looking at codebase health helps catch creeping debt early. Without that habit, you only see the mess when it’s already slowing everything down.
Q. What advice would you give to a leader who is just starting to reduce debt in their organization?
Burak: Start small and pick one issue that affects your speed. Fix it, measure the result, and use that to get support for fixing more. Don’t try to clean everything. Just fix what’s blocking progress. That’s how you build momentum without overwhelming your team.
Technical debt is not just a tech issue. It’s tied to team habits, business pressure, and how success is measured. If leadership only rewards features, debt will grow. If they reward long-term thinking, things improve naturally.
