Do you actively manage technical debt debt on your software development projects and if so, how do you do it?
相关问题
- Multi-pass C preprocessor [closed]
- How do you track time spent working on a project?
- project organization with R [duplicate]
- How to make decisions while choosing a project in
- Are there any dangers associated with using JavaSc
相关文章
- What is Scope Creep? [closed]
- class inherits unrelated defaults for spliterator(
- What is a use-case? How to identify a use-case? [c
- What Project Management software do you recommend
- How to manage a hierarchy of committers (like Linu
- organize project and specify directory for object
- Codeplex/Sourceforge for internal use [closed]
- How did you estimate the time you will spent befor
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.
Java Posse have covered the management of Technical Debt recently which looks very comprehensive.
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.).
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.
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.
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.