Skip to main content

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.

Comments

  1. Good post and great topic. I would disagree, however, that "messy code" is not technical debt. It has to be paid back regardless of the reason behind it so I would argue that it is nonstrategic technical debt. Anytime a gap is created in a technology infrastructure without due process it should be considered nonstrategic debt which is the worst possible kind. The blog post below expands on that differentiation.

    http://blog.acrowire.com/technical-debt/technical-debt-part-1-definition/

    ReplyDelete
  2. Hi Ted,

    Thanks for stopping by and your comments.

    The idea behind saying that 'messy code is not a technical debt' is to ensure that people dont use it as an excuse to claim that they have incurred technical debt. In making this statement, i strictly go with Martin Fowler's definition of types of technical debts and his statement that 'only the quadrant Deliberate/Prudent is acceptable and only for very short timeframes'. so knowingly writing bad code and calling it technical debt is a strict no for me and it is also not professional.

    Having said the above, i also understand the potential usage of this term technical debt to quantify the health of older systems which have messy code and where we dont know any other information about the system. Imagine a scenario we want to evaluate an existing system to understand how good it is. Here we can definitely use the term technical debt and this also covers the messy code.

    So the only difference according to me is that in the second scenario, we dont know why the messy code came into existence, but still use the term technical debt to quantify the technical health of the system.

    But in the first scenario, if we knowingly write messy code, we shouldn't call it as having incurred technical debt.

    hope this clarifies.

    ReplyDelete

Post a Comment

Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …