Understanding Technical Debt

I have always thought of the concept of Technical Debt to be very useful and was surprised that many technical people werent aware of the term and hence its importance. While there is lot of material on the topic, this small post intends to be a brief introduction to the concept, it's importance and it's usefulness.Hopefully, this will motivate people to read more about this and use it effectively in their work.

What is it?
Technical debt is a metaphor to understand and communicate issues related to the impact of technical decisions, in a language people easily understand and relate to. This term was introduced by Ward Cunningham to explain the refactoring he was doing in the WyCash project . WyCash was the first commercial software developed and maintained, using all ExtremeProgramming principles.

I have quoted from Cunningham to explain the reason for the debt metaphor. the link i have provided also has a youtube video for interested people.

Metaphor
       I became interested in the way metaphors influence how we think after reading George Lakoff and Mark Johnson's MetaphorsWeLiveBy. An important idea is that we reason by analogy with the metaphors that have entered our language.
Debt
       I coined the debt metaphor to explain the refactoring that we were doing on the WyCash product. This was an early product done in Digitalk Smalltalk, and it was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if we had known what we were doing all along and to look as if it had been easy to do in Smalltalk.
    The explanation I gave to my boss, and this was financial software, was a financial analogy I called "the debt metaphor". And that said that if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan.
Speed
    With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you'll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.
Burden
    I think that there were plenty of cases where people would rush software out the door and learn things but never put that learning back into the program, and that by analogy was borrowing money thinking that you never had to pay it back.Of course, if you do that, you know, say with your credit card, eventually all your income goes to interest and your purchasing power goes to zero.
   By the same token, 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 eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer. In other words, the interest is total -- you'll make zero progress.  

What is it 'NOT'?
Technical Debt should be reserved only for cases when people have made a considered decision to adopt a design strategy that isn't sustainable in the longer term, but yields a short term benefit, such as making a release or an emergency production fix. The technical debt concept, as much as it is useful, can also be easily abused. So here are a few points on what a technical debt is not. 

• Technical debt is not be used as a reason for people to take bad design decisions or write bad code.
• Messy code, produced by people who are ignorant of good design practices, shouldn't be considered a debt.
•  Intentionally doing bad design or writing bad code, with the intention of making it better, is not technical debt.

Why is it useful?
While the ideal target is to write code without any technical debt, we must understand that it is not possible since we don’t develop software or manage our projects in an ideal world. In this aspect, the technical debt metaphor helps in a good number of ways. It allows us to be conscious about the design decisions that we take and the inherent trade-offs. It allows us to communicate in a language that people understand ( debt, paying back, interest, principal).

Why is it important?
The simplest definition of good software product is any software that can be modified and tested, with minimal effort. While this looks very simple, careful perusal of the definition would mean a code base that is highly modularized, with well defined interfaces and other characteristics like reusability and modularity. Considering this definition in mind, the term, Technical debt provides a means for Technical people and Project managers to communicate the following better.

• For architects and technical people, Technical debt is a good metaphor to understand the impact of the design choices made and the trade-offs incurred.
• For project managers, Technical debt is a good metaphor to talk to Higher management and non technical people about the state of the code base and system.
• On the technical decisions taken, the term really helps managers to understand and articulate the long-term effects of short-term technical decisions, primarily from a cost angle.
• It is a well known fact that when it comes to the lifecycle of a product, the cost of developing a system is always less than the cost of maintaining and enhancing a system. In this regard, the concept of technical debt plays a key role in helping managers to keep a tab on the total cost of ownership of the software system and ensure that it is kept to a minimum.