The deadline for a critical software feature is just two weeks away. I’m in a meeting with my team to plan the work. I glance at the calendar again—it’s tight, but I think we might just make it. The team has broken down the feature into smaller tasks, estimating the effort for each one. I’m holding my breath, hoping two weeks will be enough.
Then the team gives me the news: they estimate at least six weeks. My heart sinks, and a cold sweat breaks out. This feature was promised by the deadline. But now it’s clear—there’s no way we can deliver it on time.
How did this happen?
Taking a step back, I think over the past few weeks and realize the real mistake happened much earlier. Other features were also deemed critical, so we delayed starting this one. I should have ensured we began work on it sooner. If I had reported earlier that the deadline was at risk, we could have reacted. It would have been possible to start this feature right away and postpone other tasks. Or, we could have decided to push back the deadline.
Back to the situation. Two weeks until the deadline, and I’m scrambling to find options. What can we do? Can we recheck the requirements and trim anything non-essential? Maybe we don’t need to deliver every detail right now. Could we split up the tasks even more and tackle them in parallel? I even consider bringing in external help (though I know Brooks’ Law tells me that would probably slow us down).
Unfortunately, the answer is: “There is no silver bullet.” It will take at least six weeks, and even that estimate is probably optimistic. Experience shows that every feature takes longer to develop, integrate and test than initially estimated.
But the deadline is non-negotiable. The company has a lot riding on this date, and it would be financially unviable to miss it. Now there’s only one option left: we take on technical debt.
What does this mean?
The dev team, being awesome, pulls off a miracle and meets the key requirements in two weeks. But there’s a catch: the solution barely holds together. It’s a mess architecturally, lacks proper tests, and can’t handle anything beyond this one specific case. Any small change might break it in unexpected ways. That’s technical debt. And like any debt, it needs to be paid back. In software, this means future development will be slower and buggier. The team’s not to blame—management made the call, and now they’re stuck with messy code as the price.
People often sugarcoat taking on technical debt, saying, “We’ll clean it up properly after the deadline.” But let’s be honest - how often does that really happen? That promise is usually forgotten the moment the next deadline looms.
“So, how do you handle technical debt?”
"Easy. You don’t create it in the first place."“But what if it’s already there?”
"Again. You make sure it doesn’t happen."“Okay, but let’s say hypothetically it is there. What do I do then?”
"You need a plan. Put specific actions to reduce the debt on your roadmap, and fight every day to keep them a priority. They can’t be delayed or pushed aside - it’s now or never."
A team can do a certain amount of refactoring—and thereby reduce technical debt—alongside normal development. But only if new technical debt isn’t constantly being added. Larger measures that truly reduce technical debt in a sustainable way require high priority from management. Only then can they be implemented. This investment pays off. Without these actions, the quality of the software product will suffer significantly. Eventually, neither the developers nor the users will want to work with this product.
The economic impact of that is likely greater than the consequences of a missed deadline. Therefore, it is the management team’s responsibility to keep technical debt under control.