Everybody is talking about technical debt today: developers, testers, consultants, managers - even executives.
But the more that people talk about technical debt, the fuzzier the idea gets, and more watered down the meaning of “technical debt” becomes.
Philippe Kruchten is trying to solve this by suggesting a narrower definition of what technical debt is and what it isn't. He breaks out all of the work on a system into work that is visible or invisible, and that has positive or negative value:
| Visible | Invisible | Positive Value | New Features | Architecture and Structure | Negative Value | Defects | Technical Debt |
In this model, defects that have been found but haven't been fixed yet aren't technical debt - they are just part of the work that everyone can see and that has to be prioritized with the rest of the backlog.
But what about defects that you've found, but that you've decided that you’re not going to fix – bugs that you think you can get away without fixing (or that the people before you thought they could get away without fixing)?
These bugs are technical debt – because you’re pretending that the bugs are invisible. You’re betting that you don’t have to take on the cost of fixing these problems in the short term at least, just like other kinds of technical debt: copy and paste code and conscious short-cuts in design and compounding complexity and automated tests that should have been written but weren't and refactoring that should have been done that wasn't and code that you wrote that you wished you hadn't because you didn't know the language well enough back then and anything else that you may have done or not done in the past that has a chance of slowing down your work and making it harder in the future.
The same rule applies to results from static analysis bug finding tools like Findbugs and Klocwork and Fortify which point out coding problems that could be real bugs and security vulnerabilities. After you filter out the false positives and motherhood, and the code that works but really should be cleaned up, you’re left with code that is wrong or broken – code that should be fixed.
Keep in mind that these are problems that haven’t been found yet in testing, or found in production by customers – or at least nobody knows that they've run across these bugs. These are problems that the team knows about, but that aren't visible to anybody else. Until they are fixed or at least added to the backlog of work that will be done soon, they are another part of the debt load that the team has taken on and will have to worry about paying back some day. This is why tools like SONAR include static analysis coding violations when calculating technical debt costs.
I agree that bugs aren't technical debt – unless you’re trying to pretend that the bugs aren't there and that you won’t have to fix them. Then it’s like any other technical debt trade off – you’ll need to see if your bet pays off over time.
3 comments:
"But what about defects that you've found, but that you've decided that you’re not going to fix"
I have no idea where you work but that wouldn't fly in any shop I've found myself in. Bugs are bugs and must be squashed.
Technical debt is bad architecture, lack of documentation and lack of automated tests.
@Anonymous, some teams might have good reasons for not fixing every bug that's ever found, as I've argued before in a post on Zero Bug Tolerance: http://swreflections.blogspot.com/2011/02/zero-bug-tolerance-intolerance.html
Other teams deal with bugs consciously or unconsciously like other kinds of debt: they take a bug load on because they are trading off fixing bugs with something else that is more important to them at the time, usually hitting a deadline. My point here isn't that this is a good practice, but that it is reality in many shops.
Big older systems often have bugs that haven't been fixed for some reason. If the team, or management, or whoever is paying for the work, are pretending that these bugs don't need to be fixed, they become debt.
"Lack of documentation" is interesting. I can see out of date or incorrect documentation as technical debt, if again you aren't planning to do something about it or haven't done anything about it for a while. Otherwise errors in documentation are defects. But missing documentation? How does somebody judge what documentation is or isn't needed for a system? How do you measure the cost or risk of not having more documentation, and what kinds of documentation?
This is another example that technical debt means different things to different people.
Seems overly complex. Technical debt represents future work that the technical team will need to do (with high probability). I don't why recording it as a bug is something that makes that different.
When we talk about technical debt we usually refer to work where the benefit to the user is not evident to someone outside the team or is not imminent. This is contrasted with a bug fix impacting something the user sees or a new feature providing some new functionality to the user. Both are debt though. Both incur "interest" in that dealing with them later is going to be more expensive.
Technical debt is the silent killer. It is the work that needs to get done but isn't and when it's not done it will slowly choke the project.
Post a Comment