{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 淡お忘 的问题《Do you actively manage technical debt? [closed]》','https://www.manongdao.com/q-1309354.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
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
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.
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.
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.
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.