Technical debt takes many forms
Most people are familiar with “technical debt” in terms of code or architectural problems that slow down development. There are other forms of technical debt, though, that can be overlooked.
Dead Code: There are endless “dead code as debt” scenarios. You have a “live” function that is only used from dead code, hiding the fact that this function is also dead (this situation is cancerous). Every time you grep, you have to wade through code that is dead. Every time someone stumbles across the dead code, they need to figure out if it’s dead or alive. There’s no reason for any of this (especially not “keep it around as reference”). Dead code is a debt, but it’s also easy to pay back. Remove your dead code.
Unused Repos or Branches: Every time a new person starts, they will ponder what code is dead and what is alive. This pondering includes code, issues, and documentation. It is sloppy and unnecessary. Put unused repositories in cold storage. Delete stale branches.
Large Backlog: The larger the backlog, the worse the experience of using it. It’s harder to find, reclassify, and prioritize. Some developers will not even bother. A backlog is not a place for everyone to list anything they think should ever be done. Close stale and low-priority tickets. Close “symptom” tickets that you know won’t be addressed until a system is rewritten. Close everything except 3 months of work (and manage further out work on your roadmap, which should not be in your backlog).
Dirty Wikis/Documentation: Why out of date documentation is harmful should be pretty self-explanatory. Don’t let it get that way (or just delete the documentation). Make documentation someone’s responsibility, or make it part of the “definition of done.”
Every organization has these things. By recognizing them as debt, and thus detrimental to development, it can perhaps simplify any argument about what to do.
While a valid post otherwise, I feel the urge to remind that term “tech debt” should not be used to describe any smelly situation. Tech debt is a delivery technique if you will, where you deliberately choose to use fast and dirty implementation to ship sooner, and the debt comes from the fact that you’ll “pay”, that is, provide clean implementation, later, hence the term “tech debt”.
Very good advice! And I think many people will agree, but often, even for those who agree, the problem is just the time to maintain it all. Busy schedules and a wrong definition of Agile makes good code and document management practices a luxury. “Who cares about dead branches, as long as we can ship the product? Sure we have a mess, but the client gets his stuff!”.
Personally I try to put all this in my definition of done. When you make a mess you clean up after working/eating/etc. And programming should be like that. Of course, the more of the artifacts described are created, the more you have to clean up! Therefore devs should think carefully when creating documentation, adding low importance issues to backlogs, etc. People need to take the larger system, that is the team, into account, and how this overhead and dirtiness affects the entire team.
Having regular “spring cleaning” events can also help to keep your team’s dev environment tidy and focused.
Robert: Yes! You took the words right from my fingertips.
Viktoras: While I am a stickler for words (https://www.robg3d.com/2012/02/refactor/), I disagree on that overly precise definition, where technical debt is added deliberately. It’s a very interesting technique, but a very rare actual usage, and also unnecessary for a metaphor (much financial debt debt, other than a mortgage, is not from well-intentioned deliberate acts, but lack of discipline).