Have you heard from the team that,
- We are afraid to touch that component because it is so fragile and loaded with technical debt or
- We need to address the technical debt formed due to the shortcut we took in the last sprint to meet deadlines
or something similar and wonder what is this “Technical Debt” all about?
Want to understand what they are talking about, No worries, this blog is aimed at introducing the concept of Technical Debt for a novice hearing this term.
In this blog, we will look at
- What is Technical Debt?
- Why would Technical Debt get formed?
- How can you tackle Technical Debt in software development?
What is Technical Debt a.k.a Tech Debt?
To understand the concept of Tech Debt, we will take the metaphor of Financial Debt.
The borrowers get into Finacial Debt because for the borrower, getting the asset now in hand to use is much more important than earning and accumulating the cash to buy it. So they take the shortcut to earn/accumulate the needed money through taking a debt (loan) and plan to repay it later.
Very similar to Financial Debt, Technical Debt is formed when teams take shortcuts to release the software features now (fast) rather than following the right code and design practices. Similar to acquiring the asset before earning all the required money to buy.
When you are in financial debt you would need to pay interest to the loaner who has given you the loan.
Similarly, when you are in Technical Debt, teams will pay the interest in terms of reduced flexibility for making changes, delayed future releases, fragile designs and architectures, bugs, and painful reworks.
Taking the analogy further, when financial debt grows beyond your capacity to repay and manage, you can't even manage your daily needs. Similarly when technical debt grows teams would not be able to manage, modify, run and use the software.
Why does Technical Debt take place?
There are 3 most common ways that you can find Technical Debt getting accumulated in the software that the teams build.
Inadvertent: The technical debt gets formed due to unknowing mistakes of developers i.e. due to lack of knowledge of good practices to be applied in certain design and development situations.
Intentional: Technical Debt is formed when it is intentionally introduced. A most possible reason for this type of technical debt is the pressure from the business to go to market fast. In this case, the business also knows that we are not doing it right but we want to deliver to the market to gain some competitive advantage or fulfill compliance needs by a specific date by taking shortcuts in the development process.
Reckless: Another way the technical debt is formed is due to a lack of discipline and attention to detail. This case can happen when you do not have motivated developers in your team.
How do you tackle these types of Tech debt?
Inadvertent: This type of tech debt can be tackled through constant learning and having an eye on what is coming up next in your product and technology space. This helps to visualize future needs and helps teams to do some POC and learn the good design and architectural practices for the future needs. However, sometimes it is hard to tackle this type of technical debt as the team's self-awareness (knowing that what they don't know) itself could be challenging.
Another way that you could deal with this type of technical debt is to build systems that ensure quality like automated code reviews, automated tests, and automated security checks using tools.
Intentional: This type of tech debt can be dealt with by making space to rectify the shortcuts taken as early as possible before the tech debt bloats up. Make room for clearing technical debts in your sprints. This type can also be dealt with by working closely with business partners, understanding the future needs, and effectively communicating the impact of shortcuts for the future. Communicating in their language to make them understand that impact would help. You may negotiate to create enabler technical stories if needed.
Reckless: This type of tech debt needs to be tackled by addressing the root causes of people's behaviors. More often these are due to motivational aspects of the people in the team. You could use people management techniques to understand the motivational needs of the team members e.g. you could use Management 3.0's moving motivators technique to understand the motivational needs of the team members and address them to bring in the needed behavior changes. You could also try 5 dysfunctions of the team activity too :)
Another complementing way to address this is to build systems that ensure quality. e.g. Automated quality checks, Peer reviews, Automated tests, etc.
Hope this blog clarifies the concept of technical debt and gives some ideas to tackle the tech debt in your software development process.
Hey 👋 liked the stuff here?
Subscribe to updates from Tech Coach Circle here.