Technical Debt

The problem: why has everything become slow?

Our online shop started two years ago. In those days, each new feature took one week. Now the product manager asks: “Why did a simple change in the discount take three weeks?”

The team knows the answer, but it is hard to say:

1. The discount rule is copied in three places. In the shopping cart, on the payment page and in the sales report. Each change must be done three times.
2. We have no automated tests for payment. Each change must be tried by hand.
3. The CheckoutService class is three thousand lines. Nobody dares to touch it.

Each of these was once a quick decision. We call these technical debt.

The idea: loan and interest

Ward Cunningham introduced this comparison. When we take a shortcut, it is like taking a loan:

1. The loan principal. The work we must do later to fix the code. For example, merging the three versions of the discount rule.
2. The loan interest. The extra time we pay every time we work with the bad code. For example, three changes instead of one, and bugs that happened because one of the three places was forgotten.
3. The important point. Until we pay back the loan, we pay the interest. And the interest is only paid when we touch that code.

A loan is not bad. Companies take loans to grow. The problem is a loan that nobody remembers, and interest that grows every month.

Live example: debt interest over time

In this simple model, we have ten units of time in each sprint. Each sprint adds one new shortcut. Each unit of debt eats one unit of time in every sprint. Try the two methods:

Look closely at the first sprints. The “features only” method is ahead at first. This is why this method is tempting. But a few sprints later, the debt interest eats most of the team’s time.

Four types of debt

Not all debts are the same. Martin Fowler splits debt with two questions: was it deliberate? and was it prudent?

1. Deliberate and prudent. “The sale is on Friday. We ship with a simple way and fix it next week.” This is a correct business decision, if it is really recorded and done next week.
2. Deliberate and reckless. “We have no time for design.” The team knows it is bad, but has no plan to come back.
3. Inadvertent and reckless. The team does not know the code is bad. The solution is training and code review.
4. Inadvertent and prudent. “Now that we built it, we understand how we should have built it.” This always happens. It is a sign of learning, not a mistake.

Which debt should we pay first?

Not all bad code is worth fixing. Remember? Interest is only paid when we touch the code. So ugly code that nobody changes has almost no interest.

A simple way to find these hot spots (Hotspot):

1. Count the changes. The git history shows which files changed most in the last few months.
2. Look at the complexity. Very big files, very long methods, nested conditions.
3. Put these two side by side. A file that is high in both lists is the first priority.
4. Ask the team. “Which part do you not like to open?” This answer usually matches the numbers.

# Files changed most often in the last 6 months
git log --since="6 months ago" --name-only --pretty=format: -- "*.cs" \
  | grep -v '^$' | sort | uniq -c | sort -rn | head -10

Example: merging the discount rule

Before the change, the same logic was in three separate classes:

// CartService.cs, CheckoutService.cs and SalesReport.cs (copied 3 times)
var discount = order.Total > 5_000_000 && customer.IsVip ? 0.1m : 0m;
var payable = order.Total - order.Total * discount;

After the change, the rule is in one place and in business language:

public static class DiscountPolicy
{
    private const decimal VipThreshold = 5_000_000;
    private const decimal VipRate = 0.10m;

    public static decimal PayableAmount(decimal total, bool isVip) =>
        isVip && total > VipThreshold ? total * (1 - VipRate) : total;
}

Now one test is enough, and the next change happens in only one place. This Refactoring was small. We did not need to rewrite the whole system.

How do we reduce debt?

1. Record it. Each deliberate debt becomes a task in the team’s task list (Backlog). Write where it is, what its interest is, and how much time fixing it takes. Unrecorded debt is forgotten.
2. The Boy Scout rule. Every time you touch a file, leave it a bit cleaner than before. A better name, a shorter method, a test.
3. A fixed share in each sprint. Set aside part of each sprint’s time for debt. Small and steady payments are better than one big cleanup that is never approved.
4. Attach the debt to business work. “Before the new discount, we merge the discount rule” is approved more easily than “one sprint for Refactoring”.
5. Change a big part little by little. For a very bad part, a full rewrite is dangerous. Build the new code next to the old code and move the paths to it little by little. We call this method Strangler Fig.

How do we talk to the manager?

The product manager does not understand the words “dirty code”. But they understand time, money and risk very well.

Common mistakes