I kind of like the idea of calling it technical debt- because I can declare technical bankruptcy (move companies). But really it doesn't work, partly because technical debt very often is actually the result of doing a slap-dash job in the past. If this code was unimportant enough to just throw together in the past you really need to ask yourself whether it's important enough today to fix. This feeds in to one of the fundamental personality types - someone who may be more interested in making the code beautiful and streamlined and neat than actually improving the bottom line.

There are cases where you need to consider technical debt, but most often it should be considered as something you create rather than something you inherit- because the creation of the technical debt is where you're making the judgement:

* Is delivering now important

* Is this code going to need to adapt and develop in the future

* Is the code this is building upon going to stick around or will this code likely be superseded.

* (Selfish developer: Am I going to be around to deal with this)