Most Agile teams recognize the evils associated with technical debt. Just like a financial debt, the technical debt incurs interest payments. These are paid in the form of extra effort required to maintain and enhance the software which has either decayed or is built on a shaky foundation. Most Agilists recommend repaying the technical debt as early as possible. However, most Agile teams fail to monetize the technical debt, which can give valuable insights.
Once there is a monetary amount associated with the technical debt, it helps in answering various complex and tricky questions about the software. Israel Gat suggested that unless there is a quantifiable tab on the technical debt, teams generally ignore it to a level where the software decays beyond repair.
Beyond a certain level of debt, no good option is available. The code decayed to the point in which fixing anything in a hazardous proposition – every fix is likely to break something else.
He mentioned that there is a need to monetize technical debt and represent that as a liability on the balance sheet.
According to Israel, there are multiple benefits of monetizing the technical debt.
- It tells the teams when to stop developing and start refactoring - When the technical debt reaches a certain level (say 25 cents per line of code), new functionality is put on hold. The team gets into refactoring mode and no functionality is added until the debt is brought down.
- Customers of the software get an idea of how risky the software is – Israel suggested that this is inline with the Agile Manifesto “Customer collaboration over contract negotiations”.
- Makes investment decisions easy for Venture Capitalist – VC's can determine the rationale for making an investment in a software product.
- Determines the affordability of the software – Helps answer the questions about affordability of the development and maintenance of the software as it evolves through the software lifecycle.
- Helps in making the refactor versus rewrite decision – Associating technical debt with other important factors helps in making a decision to start afresh.
- Helps in defining credit limits – Once monetary credit limits have been defined, they help all stakeholders including the CxO's to take informed decisions.
So what is the suggested way to monetize technical debt?
One of the ways is to use the technical debt plugin for Sonar. A technical debt analysis of a vast number of projects already is available on the Sonar live site. The cost is calculated by first figuring out the debt which is
- Debt(in man days) = {cost_to_fix_duplications + cost_to_fix_violations + cost_to_comment_public_API + cost_to_fix_uncovered_complexity + cost_to_bring_complexity_below_threshold + cost_to_cut_cycles_at_package_level}
There is a default cost in hour associated with each of the above violation. For example
- cost_to_fix_duplications = {cost_to_fix_one_block * duplicated_block}
Now, as per the defaults cost_to_fix_one_block = 2 hours. Assuming that the average developer cost is $500 per day and there are 8 hours to a day then to fix one such block $125 would be spent. Likewise, monetary analysis can be done for each violation to finally arrive at the total technical debt.
Thus, monetizing the technical debt gives a deep understanding of the hidden costs associated with the software. It is key for all Agile teams to keep monitoring their technical debt costs and keep them within the credit limits. Doing this helps in creating a product which is not only easy to maintain and enhance but also allows VC's to invest and customers to buy with confidence.