- Here is Ward Cunningham explaining his thoughts behind why he coined the metaphor on wiki and also in a video talk.
- Here is a blog by Martin Fowler on the topic.
- Here is a personal blog by Dharmesh on the same topic.
I am going to suggest a few things when put into regular practice can help you contain the debt to a minimum.
1. Low test coverage can contribute to hidden technical debt. When we are under time pressure, guess what gets cut from the budget? "testing!" It may seem innocuous to eliminate funding for "testing," it can push the project to bankruptcy when done on a regular basis. So, target 90%+ test coverage and track it through continuous integration.
2. The best "architecture" is not static, it is evolutionary that emerges over time. What is important though is "consistency." If we are always doing the same thing the same way, the chances of incurring hidden debt goes down. The consistent way of doing things needs to be a shared knowledge best captured as a list of "How Tos" and needs to be kept in synch with the evolving architecture. Do you have one such list for your project?
3. Review architecture at a regular interval to spot inconsistencies. I am sure you will find some even after you have a published "How Tos." As soon as you find them, fix them.
4. I have seen bugs are triaged and then some are deferred to be fixed in the future in favor of some "important" new features. The fallacy lies in the notion that cosmetic/minor bugs are harmless. What is harmless today can compound into a significant issue later somewhere else in the system. Personally, I always like to fix all bugs before I do any new development. However, I can understand that we may need to do it at times, but it should be "exception" than "norm."
5. Last but not least, if you must take on a debt, get a commitment to payback in full by a specified timeline. Then track and report on it like a hawk (not like the Fed or SEC).
How are you containing technical debt on your project? Care to share?