Is technical debt waste?

How does technical debt relate to the seven wastes in Lean Software Development?

1. Extra features – I cannot see any direct correlations here
2. Partially done work – If code that is not refactored is not done, then skipping refactoring will be valid here. But I don’t think it is that obvious. Based on that argument, we can actually motivate allmost everyting by this kind of waste
3. Relearning – Does not help me that much here, or?
4. Task switching – Nope
5. Handoffs – Nope
6. Delay – Code that is not refactored will result in delay and will take longer to maintain and make changes to. So, Delay can be an effect, but is not the cause.
7. Defects – Not really, but as with delay, sloppy code will most likely result in more defects or increased cost.

In the book Lean Software Development – From concept to Cash by Tom and Mary Poppendieck, the topic complexity is one of the first topics discussed when waste is discussed. Technical debt will result in increased complexity. Adding complexity into the code is – what I can see – increasing the technical debt.

So, my current standpoint is that putting technical debt into the code base is waste. Removing technical debt is neccessary waste that should not be needed if the sloppy code was not there from the first place.

Then the next question is how we can develop code with minimal technical debt fast enough? Well, write less code, build quality into the software via Test-Driven-Development and constant refactoring might be a good start.