Technical Debt and refactoring

Do not refactor for sake of paying Technical debt.  Refactor the code if it has business value. Hidden message: Do not pay Technical debt if it does not enhance value of software.

Perfection is mirage. Good enough is good.

Every day indicators of Technical debt

• Let’s complete testing in next sprint.
• Lot of “To Do” and “Fix Me” in code.
• Only Sonia should touch this code.
• Just copy paste this code.
• In which class we store password.
• Unit test cases !! are you joking.
• Do not worry about documentation for now.
• I can this in two minutes.
• It is OK for now. We will refactor later.
• Let’s do this way, it is faster to do. We will change it later.
• We cannot implement this feature in current technology of product.
• The velocity of team is deteriorating without change in team composition or technology shift.
• Old versions of libraries in use.
• Frequent problems in production.
• Known bugs
• Never say no to features
• Project in IDE has lot of warnings.
• At run time we get this warning
• Our Ops guys are so good, they can make anything work
• We have always done this way
• Coding guidelines!! Forget for now.
• If we release by this Friday, approximately number of 20 bugs will be there. If you can wait till next week bugs will be 5.

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.

Technical Debt – Business & Technical point of views

Business and Technical folks view Technical Debt from different perspective.  Business folks associated with a project view Technical debt as tool to:

• shorten the go to market time
• preserve the startup capital
• minimizing upfront development expense

Technical folks, view Technical debt from entirely different perspective.

• Ignorance of dev team
• Doing under engineering to avoid over engineering
• Surrender to business pressure

What do you think?

Technical debt - How to pay?

Like tax and death in life, no team can avoid technical debt in software development. Therefore we need means to manage it. To manage technical debt three broad strategies are used:

• Buffer stories
• Buffer tasks
• Technical debt paying releases

Buffer stories

Team can set aside approx. 10% of velocity per release for technical debt paying stories. This will set the expectation of business stakeholders in each sprint and help to maintain relatively technical debt free software.  These stories are created by dev team. If story is focused on function debt, let PO drive it.

Buffer tasks

During task break down (in Sprint planning meeting), if required, technical debt paying buffer task is created and budgeted. This approach ensures ease in scheduling but also raises the risk of spending resources on not so important things.

Technical debt paying releases

Instead of paying a little in each sprint, team may decide to devote larger chunk of resources periodically (generally every 6 month). This approach is works well where sprints are going on for multiple years. In this approach a risk of mounting debt always lingers on. Team should avoid Technical debt paying release just after a frenzied, time-critical and feature heavy release.

I am sure there are more ways to pay back debt.  I like to hear from you more.