I've had some trouble for a while with idea of "technical debt."<p>When I'm planning work, I can't look at something and say "I'm taking 10 points of debt with this decision, at an interest rate of 1 pt per month."<p>By the nature of how tools, libraries, frameworks and languages evolve, our implementation today will likely be inefficient compared to what we could build 24 months from now, may not be well-tailored to button up next to a system we haven't yet purchased/implemented, etc.<p>As we don't have time machines or crystal balls at our aid to predict what the future will hold, it's always seemed more helpful to focus more on how to design a solution for modular improvement. If any given component could effectively be isolated and then refactored or replaced, you can look at those issues more as continual improvement.<p>My experience has been that, if maintaining and continually improving existing code can be respected in the organization with the same value as new feature development, a lot of the angst goes away.