3

I am new to software engineering and looking for someone with agile experience to help me understand what the recommended practice is and why. If this question can be related to a better site please note that site please.

Improve this question
1

3 Answers 3

Reset to default
4

Technical debt is not really "added" to projects (or rather products), it just accumulates like dust or mould if not taken care of. Technical debt is basically undone work, like not cleaning up the dishes after cooking. You can get away with it for a while, but the longer you keep it, the more it costs to actually get rid of it, and the more it slows you down.

So the recommended ideal approach is not to let technical debt accumulate, rather do the cleanup right away whenever it is required. In software, cleanup is called refactoring. If you are living in a less than ideal world like most of us here do, technical debt is prone to accumulate though every now and then. So one should focus on dealing with it regularly, in small but frequent steps, rather than trying to resolve it in a large chunk at once.

Improve this answer
1

On some projects, you inherit several thousands of bug reports. It can be daunting if you attempt to encompass all of them.

  • The best way is to go forward: You can develop new features, but make sure you don't repeat the same mistakes - Do include enough time for clean-ups and refactors.
  • Practice the "Zero Bug Policy": At the end of each release, either you still have bugs and you postpone the release, either you close all bugs as "Won't fix". Please read the linked article, it says a lot about 1,000-bugs long backlogs.
  • If you're given a project with enough slack time to look at the technical debt, it's not a good sign. The added value of your work may be difficult to demonstrate.
  • You should prioritize user stories according to their value and estimates. If a user story includes a technical debt item, you'll have time to refactor. If a technical debt item isn't linked to a user story, it doesn't have any value to improve it.

I've regularly worked on projects with more than 3,000 open bugs and we just ignored them and closed old ones regularly. Those who care about those bugs may reopen them in time, but most probably most of them are long forgotten.

Improve this answer
0

The answer is that there's no magic formula.

I've found however this document of the Construx guys (the same guys of the classical mistakes paper) in the Software Engineering Institute repo very rich to make my own definitions. BTW this is a lite version of their Technical Debt Management approach.

I hope it's as useful for you as it was for me.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.