Good and Bad Technical Debt
ByOn November 3, 2014 At 9:00 am
Responses : One Comment
Technical debt is usually always referred to in a negative sense, whether it be how to avoid it or how to get rid of it. However, here is a post that distinguishes between good and bad technical debt. This post makes the point that in most systems, when graphing their technical debt curve it consistently increases over time making changes to code more difficult and lowering productivity. When thinking about the ideal tech debt curve, most people would answer to maintain zero tech debt over time, when in fact this could also slow down work as technical debt in the short term can be a savvy business tool.
Using “a mess” as another way of explaining technical debt, this post clarifies that a mess in the moment of creation in fact helps maintain the work flow. The phrase: new debt is good and old debt is bad becomes the basis for the rest of the post. This argument supports the idea that breaking large features into smaller sub features that can be completed in a few days before accumulating too much debt to clean up. Using this idea of accumulating good debt and then paying it soon after, the ideal tech debt curve would be a sawtooth pattern. The only difference is that in reality the curve would be returning to the debt baseline not zero, meaning that code is not perfect but well managed. The post also recommends, that even cleaning up after each iteration there is still likely to be a tech debt build up, and thus having a debt ceiling to keep debt from getting too out of control would be useful. Of course setting a debt baseline and ceiling is the next step so it is recommended to use a quality scale (ex. 1-5 with 1 being very poor and 5 being perfect). In the scale, there must be set limits to what is acceptable as the baseline (anything that is a 4 is at the baseline, anything lower than 3 passes the debt ceiling) and what is acceptable as the ceiling. Updating the definition of done, to a fuller concept (including tests and documentation in all code) can also help maintain a steady level of quality.
This post goes into depth of the techniques to maintain a good use of technical debt and how to stay away from bad debt (with some interesting graphics to visualize the concepts as well). To read the full post go to: http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt