On Technical Debt

Two Definitions of Technical Debt

Ward Cunningham

Ward Cunningham, who originally coined the term, said in his video blog on the Debt Metaphor that he intended to address the situation, where a team deliberately decides to advance knowingly with a less than optimal solution, because the problem domain is not yet fully understood. But to allow the team to learn from the application and not to fall into research paralysis, implementing the feature as best as it is currently possible is vital.

The following quotes are taken from the Debt Metaphor and are given for those in a hurry, since I recommend watching Ward Cunningham on this topic. They should explain what this metaphor is all about, before we have a look at a second definition.

With borrowed money you can do something sooner than you would otherwise, but until you payback that money, you are paying interest.

If we fail to make our program align with what we then understood to be the proper way to think about our [...] objects, then we will continuously stumble over that disagreement and that will slow us down, which is like paying interest rate alone.

Of course you would eventually go back and as you learned things about that software you would repay this loan by refactoring to reflect your experience that you have acquired.

If you develop a program for a long period of time by only adding features and never reorganizing it to reflect your understanding of those features then even that program simply does not contain any understanding and all efforts to work on it take longer and longer. In other words the interests' total, you make zero progress.

Martin Fowler

Many people working in the software industry today seem to follow Martin Fowler's definition of Technical Debt :

You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.

A developer (or team) decides to move forward fast by sacrificing some (or all) good software development practices. This way a dead line is met by burdening the project with a debt that has to be paid back later as there is more time or are more resources available (happens every day, huh). Taking this option requires a crucial moment for the success of the project.

Software Craftsmanship

Ward Cunningham

Ward Cunningham is in line with the notion of software craftsmanship and clearly opposes the definition of Martin Fowler and others:

I am never in a favor to write code poorly, but I am in favor writing code to reflect your current understanding of a problem, even if this understanding is partial.

Technical Debt is not about deferring work, but deferring the point of fully understanding a problem. We should call situations where poor code is written like what they are: writing poor code due to lack of time and courage to refuse to do so. This is because otherwise we ennoble writing poor code by giving it a fancy term. This is quite similar to Andrew Hunt's pragmatic programming that intends to address finding the appropriate solution for a given problem. But instead of reducing the amount of over-engineered solutions, it is now often used by programmers to make writing quick-and-dirty code some form of modern design.

Martin Fowler

But why is Martin Fowlers definition so attractive to many IT professionals?

First, it might be that the term Technical Debt is a concept that can be easily grasped and accepted by the business sponsoring an IT project. And communicating a technical problem to business people is often hard.

Second: like a doctor not cleaning her hands before conducting a surgery, there may be dramatic reasons to go for neglecting professional IT working standards, too. This completely vaporizes what software craftsmanship is all about. The root cause for this problem is usually this, given by Tom DeMarco at the OOP 2011:

If someone is finished too late, s/he probably started too late.

As IT professionals we tend to make sacrifices on qualities that are less observable to the end user. Maintainability is usually the first to let go.

Third: Messy code is all around. It has to be reduced and the Technical Debt metaphor is a way to deal with it. From the business point of view there is no difference in spending money to pay back debt of either form. Both slow down the performance of development.

Two Kinds of Technical Debt

I want to propose to distinguish between two kinds of debt. One that is done consciously, as defined by Ward Cunningham. For instance taking a debt to buy a house. And there is the other one that is done unconsciously, maybe addictively. E.g. continuously spending more money on consumer goods than someone's monthly salary can cover. The first is a practical tool, the second describing a practice of a fool.

So if we, as software developers provide more messy code per iteration than we can clean-up in the next, we are constantly taking debt. And if messy code is all around, it will be hard for everyone on the team not writing similar code (see broken window metaphor by Andrew Hunt).

Cost of Cleaning-up

To clean-up technical debt in the sense of messy code, Frank Buschmann proposed a rule of thumb on OOP 2013 to calculate its cost: it is the same amount of work as creating the solution with the technical debt. If the code is already in production, add 30 to 50%.

In case of Ward Cunninghams version of technical dept, where the latest understanding of the problem domain is coded by clean software development practices, changes may be a lot easier. This is because this code is maintainable. If your understanding of the problem domain has been completely wrong, changes may be difficult and costly, too. But the purpose of your previous work has been met: you have learned about your domain.

The Problem with Compound Interest

As a last point in this article, I just want to stress the part of the need to pay the debt back. If we won't, we will have to pay back compound interest that is introduced as soon as developers struggle with the quick fixes and are tied by the poor solution to also (and probably by the same reasons) add poorly written code, yielding even more mess.

Money bearing compound interest increases at first slowly. But, the rate of increase being continually accelerated, it becomes in some time so rapid, as to mock all the powers of the imagination. – One penny, put out at our Saviour’s birth to 5 per cent, compound interest, would, before this time, have increased to a greater sum, than would be contained in a hundred and fifty millions of earths, all solid gold. But if put out to simple interest, it would, in the same time, have amounted to no more than seven shillings and four pence half-penny.

Source: Wikipedia This thought experiment by Richard Price, done by 1772, is simply telling us that the human mind can barely cope with exponential growth. So this may be an explanation, why software degrades at an increasingly speed.

Conclusion

Ward Cunningham's version is a helpful tool of the XP toolbox. Not every mess is a technical debt, sometimes a mess is just a mess.

Martin Fowler's version may be necessary to deal with extreme situations. But there should be a plan to pay the debt back.

I think that it is important to know these two definitions.

Try hard to not start a mess today, you cannot handle any better in the future.