Do you actively manage technical debt? [closed]

N

10

25

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

Natatorium answered 10/9, 2008 at 22:15 Comment(2)

This question appears to be off-topic because project management questions are no longer on-topic. See pm.stackexchange.com. – Cowan 6/6, 2014 at 13:54

I'm voting to close this question as off-topic because project management questions are no longer on-topic. See pm.stackexchange.com. – Susann 14/2, 2015 at 4:22

I

11

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.

Infielder answered 10/9, 2008 at 22:31 Comment(1)

I posted some techniques and tactics on technical debt here: benlakey.com/2012/06/18/technical-debt – Mcgriff 19/6, 2012 at 1:38

W

4

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.

Wargo answered 10/9, 2008 at 22:23 Comment(0)

L

2

I think it's important to schedule time for dealing technical debt if you are trying to make up for old sins, but I also think you should not make this a habit. Once you clean up the mess you should avoid putting your project into more debt, unless you have good reasons for doing so.

Actively managing it like Mike suggests seems like the most reasonable approach, but I think it's very important to make it clear (to your team) that you should not schedule time or plan for refactoring in the long run.

Refactoring should be a natural part of writing code, and thus should be included in your other estimates and plans, and not be treated as a separate activity—unless you have to, i.e for "historical" reasons or because you consciously decided to implement something a given way and then re-implement it later.

Lindley answered 10/9, 2008 at 22:56 Comment(0)

S

1

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.

Stemma answered 11/12, 2008 at 18:27 Comment(0)

H

1

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.).

Herdic answered 11/8, 2009 at 11:27 Comment(0)

I

0

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.

Intrigue answered 30/9, 2008 at 10:9 Comment(0)

S

0

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.

Scopas answered 11/12, 2008 at 18:53 Comment(0)

H

0

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.

Hectare answered 11/12, 2008 at 19:7 Comment(0)

N

0

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

Natatorium answered 11/8, 2009 at 11:12 Comment(0)

E

0

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.

Eyas answered 18/4, 2013 at 15:59 Comment(0)

Recommended topics

Hot tags