What is Technical Debt and why is it important?
By Anil Jaising Published On July 24, 2021
Ward Cunningham first coined this metaphor called Technical Debt. He described it eloquently in an OOPLSA 1992 paper as well as documented on his Wiki. The fact that software systems are complex and you learn more as you build it inherently means that a lot of upfront design might not work. As you learn more you will need to make changes and we will have to spend time and effort to refactor work is very similar to paying interest on a financial loan.
Martin Fowler in his TechnicalDebtQuadrant Blog further categorizes the metaphor into the four quadrants.
Imagine having a credit card and if you continue to charge it and don’t pay back, interests will accrue and over time you can see your credit score reduce and there might be other dire implications. That is an example of reckless and deliberate spending. While on the other side there is prudent where as Ward speaks about in the vide, you deliver the best based on your current understanding and as you learn more you refactor. Similar to a mortgage on a house, you prudently pay down the principal and interest.
Now let’s look at some examples. Although the metaphor came from Software Development, I want to start with an everyday example first.
Example 1: Let’s say you and a partner, who lives in another city or state decide to collaborate and write a book together and. you decide to use google docs to write and share your drafts. As chapters get written many a times you might find that one person might inadvertently overwrite the other person’s work or make changes that might end up in rework. That’s an example of technical debt. If you have ever collaborated with someone, you might know many more scenarios to add to what I have shared in this example.
Example 2: This next examples is from my personal experience, I was an Agile and technical coach for an 80 member team working in a bank. The product was mission critical and served a very important need of onboarding clients to the bank. The changes were regulatory in nature and were part of 2-3 year effort worth of features that needed to be built to upgrade to the customer standards that the regulators wanted us to reach. These features were time bound and the product owner, stakeholder and management were pushing the developers to deliver on tough deadlines. Well what do the developers do in turn. They put design and stability to the wind and continue to bolt on feature after feature to meet the deadlines.
This worked for a year or so until the point where enough hands had built the product into something very complex and each hand that touched it left some technical issue untouched fully knowing in many cases that they could have refactored it.
The product had 4000 users around the world and one Friday, the system could not be brought up on any workstation by any user. It had become so slow to a point where it was unusable. This lead to tremendous embarrassment at all levels and was a huge incident for the bank. Imagine not being able to onboard customers so that they can conduct business with them!!!
This is a great example of reckless accumulation of technical debt to a point where the product becomes bankrupt.
I know you will be like what happened next? Well for continuing to read the story further, Head to the Engineering Practices Blog
I would love to hear your feedback and comments on this article.
About the Author
Anil Jaising is a Certified Scrum Trainer®, Certified DevOps Institute Trainer and a Certified Training from the BACK of the Room – Virtual Edition Trainer. Anil teaches Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO), Advanced Scrum Master (A-CSM) workshops from Scrum Alliance He also teaches Training from the BACK of the Room In Room and Virtual Edition). He is also the chief product owner of a telemetry plugin At A Glance on Atlassian Jira.
Scrum, Product Management, and DevOps: Simplifying the jargon
The internet and social media are full of Agile, Scrum, Product Management, and DevOps jargon, including incorrect and misunderstood concepts. This could be problematic for a learner seeking knowledge. Without a course with Scrum Alliance, Scrum.org, or DevOps Institute, this knowledge is difficult to achieve.
The Concepts & Beyond blog is a free suite of articles and videos packaged in tiny chunks. You will learn or refine your knowledge and skills to help your team and organization be effective. When you want to take your knowledge further, we invite you to join us for our Certified ScrumMaster(CSM), Certified Scrum Product Owner (CSPO), Certified DevOps Engineering Foundations (DOEF) and Training from the Back of The Room courses across the USA and Canada.
August 20, 2021 at 1:31 pm
Well thought out Thank you!
August 20, 2021 at 1:52 pm
We can all relate to top end pressures and time sensitivities. Very well said!
August 26, 2021 at 12:01 pm
The examples added a deeper understanding on the importance of dedicating time and effort on making necessary changes.
August 26, 2021 at 1:12 pm
I like the analogy of “managing technical debt” akin to paying off a mortgage prudently. Technical debt (and housing debt) is inevitable, it’s just a matter of how you avoid “missing payments” and staying up to date on your mortgage.
6 Comments
Well articulated article with examples clarifying the concept of Technical Debt. Thank you.
I liked this article aswell, It was easy for me to grasp the Technical Debt concept with the examples, great job.