Technical and Financial Debt

Most of us are familiar with Financial Debt. Let’s try to draw analogy for Technical Debt from Financial Debt.

Short-term Debt

In financial domain, short-term debt is used to finance temporary cash flow like financing of raw material for an order. As name suggest, it is expected that short term debt will be paid back on priority, generally short-term debt is expensive.

In technical domain equivalent short-term debt is debt assumed to ship code to meet deadline with known bugs, having understanding that immediately patch will released to fix the bug. Second example is hot fix for a P1 issue.  In all of cases, focus is – let’s ship/fix the code NOW, resolve the issues in immediate future.

Long-term Debt

In financial domain, long-term debt is used to finance long term goals of enterprise, generally investments like acquiring plant and machinery, acquiring competitor, etc. Generally long-term debt is cheaper to service. Long-term debts are assumed for strategic reasons.

In technical domain equivalent debt is writing a code which is UNIX specific as most of the prospects are on UNIX. It is possible that long-term debt is camouflaged as strategic architectural/design decision. When long-term debt is camouflaged as strategic architectural/design decision, never paid but does not mean it is free. There might be some opportunity cost associated with it as never approached market segment.

Interest Payment

There is no free lunch. Once you assume debt, you need to pay back it with premium. As a business and/or technical person, you need to decide, can you afford the interest and absolute amount of outgoing benefits. 

Technical debt can be pay backed regularly (with each sprint), in spurts (with each release), in one shot (bug fix release). You may also decide not to pay debt at all in case of end of life products.

Expected Cost/Value

If you purchase a car now, you may commute farther for job, so potentially earn $2,000 extra each month. The car price is $10,000. If you delay purchase of car, you may not have promised job. Are you willing to assume debt to purchase car?

If you do not release product now (before FIFA cup), no one will buy it. Are you willing to cut corners to meet the deadlines?

Opportunity Cost

What else can be done with this money/resources? Instead of following the strict coding guidelines, can I cut corners and release the product early and utilize saved (?) resources to release new features?

Present Value

Your startup needs this particular sale now even with lower margin.  Present value of debt is function of Expected value and \opportunity cost.

Debt Service Coverage Ratio

Debt service coverage ratio (DSCR) is the ratio of cash available for debt servicing to interest, principal and lease payments.

In Technical debt realm, DSCR may be defined as ration of resources available to develop software to resources spent to service technical debt.

Credit Rating

Credit rating of any individual or business depicts confidence of market in paying back the debt. 

In software development domain, credit rating of a team or product symbolizes the capacity of accruing/acquiring new technical debt.  Team/Product having less technical debt and specifically less unintentional technical debt has capacity to acquire more technical debt.

Acquired debt

A team may be very careful in assuming technical debt. But say due to product acquisition or bug in library used, team gets technical debt.

Minimum sprint payment

Team may decide to pay back technical debt in regular sprint cycle to manage total debt in reasonable limits. This is achieved by choosing debt paying stories in each sprint.

30 days, same as cash

Sometime paying debt immediately does not result in any interest. For example, in few initial sprints, there is no continuous integration.

Retiring Debt

Unlike financial debt, when a product is retired, all technical debt also retires. You do not pay it J. 

As product reaches end of life, cost to pay technical debt may not be justifiable.

Parting Notes

Unlike Financial debt, you may not pay back technical debt. In some cases paying back technical debt may not have any technical & financial justification. For example Technical debt in case of:

·         product is reaching at end of life

·         part of code which is not evolving/changing 

need not to be paid.  Therefore, In case of Technical debt probability should also be a factor while paying it back.