Technical Debt

According to wikipedia…

Technical debt is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. I’d like to talk to you about something more physical instead:

First, someone planted a hedge. Then the bushes grew into trees, weren’t good as a hedge any more, but they left anyway… and built a wall too. After some time, they wanted to keep sheep in, so added some barbed wire to stop them climbing over the wall. And now we have a (rather amusing looking) bodge: it would have been better to rip it all down and have a proper fence instead. I think you’ll agree that (whilst quite attractive with the greenery) it is a bit of a mess. Let’s translate this now into software development.

How do you know if you have technical debt?

Almost by definition:

• New features are slow
• Bug fixes are slow
• Developers say the code is crap and messy
• There is extensive documentation separate from the code itself
• New starters take a long time getting up to speed

What can I do about technical debt?

Like other Agile Coaches, I’ve seen lots of ways teams can get better at this:

• Realise as a team that there is a problem
• Allow developers the time they want to get the code good, as part of each story
• Add “technical debt” stories / work parcels
• Write (and live by) coding standards
• Write (and live by) definitions of done
• Do code reviews
• Consider trying pair programming

There are lots of other things you can do too. I’d recommend avoiding a big rewrite and do improvement incrementally if you can, as this increases your feedback. Use your noggin: If you’re refactoring code, do the most-often-changed bits first. And if your stakeholders are hesitant to invest in this, measure your Lead Time and show them how it gets better on the parts of code you’ve improved.

Any comments on this topic would be great! Do you have other ideas for removing technical debt?