Idle Thoughts on Technical Debt

Technical debt is a term of art that describes code that has outlived its usefulness but hasn’t been removed from the project.

For example, it can be used to describe code that was written before the requirements were fully understood and is found to be lacking once more information is available. Rather than rewrite the code from scratch (which is likely better in the long term), developers often hack around the substandard code’s limitations (which can be better in the short term.)

Another form is code that exists to implement a feature that is no longer needed. Disabling a feature generally only requires deleting a single line of code which renders hundereds of other lines obsolete.

Technical debt is an inevitable part of any evolving software system. There is rarely a business case to remove dead code or rewrite a whole module into a more efficient version, and developers rarely have the patience to do the kind of analysis necessary to remove all debt even when they have the time.

Too much technical debt makes software hard to update, slowing developers down. However, spending an inordinate amount of time removing the debt will also slow developers down. Therefore, it is something that developers must manage. When adding features to a project, and especially when fixing bugs, developers must allow extra time to remove some of the debt.

When velocity is high, project managers must prepare themselves for the inevitable complaints of too much debt buildup and should build in a “slow down” period, encouraging developers to attack the debt. When velocity is low, it would be helpful to determine if it’s because of debt buildup. If so, then allow for the velocity to slow even further to give the developers a chance to attack the built up debt.

Knowing exactly how much debt is acceptable, and what debt is most costly, is not something that the industry has found a way to quantify. To date, developers use subjective feelings about the state of the code rather than any hard metrics on how much is too much, or when too much time is being spent removing debt.

In my opinion, having general stories with titles like “pay down debt” or “refactor code” are a mistake. It encourages developers to cast around looking to clean up the low hanging fruit. But if a developer is complaining about a particular module being a pain to work with, that’s a good time to create a story to replace that particular module with something that has been better designed. Also, when determining story points, developers should be encouraged to consider if there is any already existing code that the new feature depends on which could use a going over, and bump up the points for the story to give them a chance to do that. This is especially true when it comes to fixing bugs. A bug in the code is a great time to realize that the module containing the bug likely has too much debt and the developer should consider doing more than just making the code work again.