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.
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.