Strategies for Dealing With Technical Debt

Here are some of the strategies that DAD promotes when it pertains to technical debt:

1. Do a bit of up front thinking. One of the process goals of DAD is Identify an Initial Technical Strategy. By thinking through critical technical issues before you implement your solution you have the opportunity to avoid a technical strategy which needs to be reworked at a future date. The most effective way to deal with technical debt is to avoid it in the first place.
2. Have an explicit architecture owner. The Architecture Owner (AO) on a disciplined agile team is responsible for guiding the team through technical decisions, particularly those at the architecture level. AOs often mentor other team members in design skills, skills that should help them to avoid injecting new technical debt into the environment. They should also be on the lookout for existing technical debt and where appropriate motivate the team to address that technical debt when appropriate.
3. Be enterprise aware. Disciplined agile teams are enterprise aware, realizing that what they do should leverage and enhance the overall organizational ecosystem. They will work close with your enterprise architecture and reuse/asset teams, if you have such, so that they can take advantage of existing assets. Assets could include code, patterns, services, templates, guidelines, or anything else worthy of being reused.
   An important strategy for avoiding technical debt is to reuse existing assets and not rebuild or rebuy something that you already have.
4. Refactor technical debt away. DAD provides guidance for when to apply several forms of refactoring, including code refactoring, database refactoring, and user interface (UI) refactoring. Refactorings are typically very small, such as renaming an operation or splitting a database column, so should just be part of everyday development. Rework, on the other hand, is more substantive and should be explicitly planned. The Architecture owner will often negotiate rework-oriented work items with the Product Owner (the person on the team who is responsible for prioritizing the work).
5. Regression test continuously. One of the easiest ways to find problems in your work is to have a comprehensive regression test suite that is run regularly. This test suite will help you detect when defects are injected into your code, enabling you to fix them, or back out the changes, right away.
6. Automate code/schema analysis. There are many tools available for assessing the quality of your code and even your database schema. Disciplined agile teams will include the use of these tools in their continuous integration (CI) strategy. Knowing where your technical debt exists is the first step in removing it.
7. Measure technical debt. Organizations that are serious about technical debt measure it, something that code/schema analysis tools help with, and more importantly keep an eye on the trends (which should be going down over time). You may choose to track code quality metrics, data quality metrics, usability metrics, time to address defects, time to add features, and many other things.
8. Explicitly govern technical debt. Several of the previous strategies require investment that some organizations wouldn’t normally consider to be part of the mandate of a delivery team. For your organization to succeed at reducing technical debt it must be governed, albeit in an agile fashion. This means it needs to be understood by senior management, measured (see previous point), and funded. The DAD framework includes explicit guidance around how to govern agile teams effectively.
9. Reducing technical debt should be part of your culture. Technical debt isn’t going to fix itself, and worse yet will accrue “interest” over time in the form of slower and more expensive evolution of your existing assets.
10. Address technical debt before handing over an asset. Passing systems with high technical debt to other teams, such as a sustainment team or maintenance group is generally a bad practice. It should be ingrained in your culture that each team is responsible for keeping the quality of their solutions high. It is reasonable to expect maintenance groups to resist accepting systems that have high technical debt.
11. Accept some technical debt. Sometimes you will decide to explicitly accept some short term technical debt for tactical reasons. Perhaps you need to get something developed quickly because you are running a market experiment (a la Lean Startup). Perhaps there is a new component or framework about to be delivered by another group in your organization, so you’re writing a small portion of what you need for now until you can replace it with the more robust asset. Regardless of the reason, part of the decision to accept technical debt is to also accept the need to pay it down at some point in the future. Having good regression testing assets in place assures that refactoring accepted technical debt in the future can be done with low risk.

Reference:

Scott Ambler. ۱۱ Strategies for Dealing With Technical Debt