Technical Debt can kill your product, learn 5 simple rules to deal with it.
Developers are hard to understand: they live inside the code, and their priorities focus the code. If you give them complete freedom, they will work and rework the code over and over. But, if you ask them to rush on delivery, they lose velocity; each new functionality becomes more and more costly. So, how can we manage technical debt when developers do not give us the right information?
📝 Rule 1: Involve developers with customers. 🔗
Developers need to know the value of their work. Letting them feel how the customer reacts to the product makes them focus more on the product and less on the code. Developers gain objectivity about their own technical debt and their reporting become more reliable.
I have found recently that involving the developers improves their commitment and engagement. If we make developers part of the decision, as simple as asking them about how, they acquire better ownership of the features.
📝 Rule 2: Track story point inflation. 🔗
Technical debt is more than something that you borrow that you might need to repay in the future, it is also paying interests in each feature. Compare the cost of current features with the past ones, if similar tasks are getting bigger, probably you are accumulating too much technical debt.
📝 Rule 3: Reduce architecture runaway to the minimum. 🔗
Developers have fear to change. They are afraid that any change, does not matter how small it is, could break the product and introduce unpredictable bugs. To avoid change, developers try to guess future requirements and foresee all required code architecture to support it. But it is a guess, not a certainty, and they fail. Once it is created, the fear to change makes it difficult to adapt it to real needs. The bigger is the architecture runaway, the bigger are the chances of creating technical debt.
Corollary: Do not let developers advance too much future needs.
📝 Rule 4: No large refactors; do not stop delivering. 🔗
Developers that work with technical debt feel trapped. Every new feature increases the effort. Until one day that they decide that it is enough, and they ask for a great refactor: spend some time reworking code without delivering new features. And probably at that point you are wishing for it, new features are becoming harder to deliver. Do not let them stop delivering.
Propose developers to do a progressive refactor feature by feature. Let them think in the code that will solve their problem, how to adjust the existing one, and how make it coexist with the previous one. Let them spend an extra time to refactor a bit of the code at each feature, but, without stopping delivery.
📝 Rule 5: Ask developers to be Boy Scouts 🔗
Technical debt always accumulate. If it accumulates too much, interests compound and the cost is too big. The best return of investment is doing it as soon as possible, but not too much, just a bit.
Ask developers to behave like Boy Scouts, to leave the code cleaner than they found it.
Conclusion 🔗
That is all that it takes to keep technical debt under control.
If you want to know more about the Technical Debt, how it is created, and what are its implications, please read What is Technical Debt?
Bonus 🔗
Ward Cunninghan explains the origin of the metaphor Technical Debt. It is not about delaying part of the work so may be one day we will repay it, but about interest and how they make each feature more and more costly. Ward Cunninghan coined the “Technical Debt” metaphor in 1992.
Debt Metaphor | video (04:43 minutes) 🔗
Ward Cunningham reflects on the history, motivation and common misunderstanding of the “debt metaphor” as motivation for refactoring.
