Do you actively manage technical debt?

Question

Do you actively manage technical debt debt on your software development projects and if so, how do you do it?

Answer 1

On our teams we actively manage technical debt. We do Scrum, so we spawn a technical debt card for either the current iteration or the next iteration depending on the estimate and our remaining sprint capacity and they get prioritized just like features and bug cards do. We also manage larger, cross-team debt items by having a cross-team backlog of technical debt that we prioritize and inject into each Scrum team during their sprint planning.

Answer 2

One aspect of managing technical debt is in convincing non-technical managers that you need time allocated for refactoring and bug fixing.

Here's an article with specific suggestions on how to do that.

Answer 3

It depends a lot on the product. When I worked in a field where our code had to be outside-audited it was a planned part of our sprint. PM just asked development what area needed refactoring and it was put in the plan. That's not to say you wouldn't fix the code in the area you were working on, but you wouldn't devote a day to rewriting a mangled chunk of code that worked. Now I'm working in scrum and developers just do it as they work. My impression is that about the same amount of time goes into refactoring work, either way.

Answer 4

What you do is create a culture where technical debt is not acceptable unless in extreme cases. Much like people who only pay cash and use credit only as an absolute last resort.

Answer 5

I agree with Anders. If you have to set up systems for managing technical debt, that means you're still adding it. Stop going into debt in the first place by upgrading your definition of "done".

This does mean that "indebted" modules will be harder to work through. Developers should be aware of this and assign more story points so that they leave things "done" in their wake.

Answer 6

If you're late into release cycle you don't want to change the code base too much. This means there will always be some technical debt. I usually write FIXME:s for the changes that are suboptimal and then I take care of them before I start to implement features for the next release.

Answer 7

Java Posse have covered the management of Technical Debt recently which looks very comprehensive.

Answer 8

If I really need to pile up technical debt, because I need to release something NOW, I file a critical bug about it, so it gets highest priority. But it is only for extreme situations (the client is jumping up and down, the wife is looking for a dingbat etc.).