Do you actively manage technical debt? [closed]

Answer 1

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 2

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 3

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 4

On the projects I have been involved so far, some technical debt has been "paid" (managed) only at the beginning of new phases of the projects, i.e. after "big releases" or milestones.

A very important aspect about technical debt is that it not only involves developers but management as well. In that sense, I am aware that the best way to deal with it, is to make it visible to "non-technical project stakeholders" who might allocate time and resources to manage the technical debt once they understand its implications.

This article discusses several types of technical debt, which ones might be healthy, and specially how to manage and track the technical debt load.