Urgency, importance and technical debt

A useful piece of time management advice is to distinguish between tasks that are urgent and tasks that are important - and then to ensure that important-but-not-urgent tasks (which are often overlooked) actually get done. Which seems a lot like the advice for software development teams to avoid technical debt. Repaying or avoiding technical debt is important but is rarely foremost in the minds of customers or managers. And despite the adage that "you'll pay for it [technical debt] today or you'll pay more for it tomorrow" software development organisations are often unwilling to confront the scale - or implications - of the problem.
Reflection: Do you find yourself fighting fires more often than you are creating fire engines? Is refactoring treated as an optional extra task in your estimates? How might you maintain a better level of slack? What can you do if you recognise the symptoms of undertime in yourself or those you work with? What time management lessons would your team learn if time were available for retrospectives between project releases?

Postscript: I recently caught up with Dave Hoover's blog and this entry struck a chord. To bring this back into the realm of software development, the problematic symptom is time pressure. The fundamental solutions that could treat this symptom include delaying the release or shipping without the functionality... One of the easiest and most immediate ways to suppress the symptom of time pressure is to stop writing unit tests.