How often do you have to go back and just focus on technical debt?

Do you devote scrums/iterations for technical debt? If so, how often?

What do you consider to be technical debt?

Comments

[Adam Brandizzi]

Here at Liferay many teams do this. I, personally, do not like it. What I used to do was to create tickets for every change I'd like to see. Then, when that technical debt made some story or bug hard to process, I'd then fix the technical issue as part of the story and bug.

It was nice because:

1. we were always delivering value;
2. the most costly debts were paid, while some of the ones we hated the most proved to be irrelevant; and
3. the fix of the debt was better: sometimes we dreamed about some specific refactor to be done, only to do it when needed and see that what we imagined as a solution was not the best approach.

I guess Ron Jeffries gives a good explanation of what I think is a better approach to technical debt.

[Xing Wang]

Ron Jefferies article seems very good. First time I read that one.

[buphmin]

For me and where I work it is kind of a case by case basis. Sometimes if it is a small scope change we will simply make the change and do a full regression. For bigger changes it usually requires more planning and meetings to determine if we can make the change within our schedule.

As far as what technical debt is, well it is simply code that is hard to maintain and add new features to. One perfect example for my company is a web page where the user can enter a lot of different data and select many options resulting in something like 50 million combinations of options. The way this code is written means that if more than 1 person works on it there is pretty much guaranteed to be horrible merge conflicts, incompatibilities, and hidden edge case bugs that can only get found in production. This wastes a lot of time and makes maintenance difficult.

[Quentin Sonrel]

On past jobs/projects we (me and the team, if any) never really cared about technical debt nor had a process to take care of it.

On my current project, the only technical debt we (me and the project manager) care about is the one reported by our code inspection tool (SonarQube). I usually have a look at it when I have time (usually a bit before the end of a sprint) and try to fix as much as I can. That's a very small scale project so that works for us.