Technical Debt
Updated: Sep 26, 2020
"Choosing 'right' over 'pleasant' is the sign of power"
- is an important lesson from Bhagavad Geeta. If you translate this to a developer's language, this is called 'Technical Debt' -
"Choosing a low-quality easy fix instead of the right solution".
We come across many such situations in our life when we choose a quick fix over the 'right solution' 'for time being' promising ourselves to 'handle it later' when the time permits. However, once the issue loses the priority (due to the applied quick fix or patch), we never get that permission from 'time' to handle it.
Let us assume first thing here, nobody takes technical debt willingly. Therefore, let us strictly keep 'Human Factor' out of. Apart from that, there is always a factor or a series of factors that make us take technical debt. Now, if the assumption is correct, Technical Debt's can be mostly categorized as -
Knowledge vs Schedule Technical Debt (KSTD)
Environment-related Technical Debt (ETD)
Priority-related Technical Debt (PTD)
Knowledge vs Schedule Technical Debt (KSTD)
In short: When we don't know what to choose.
We chose a low quality easy quick fix because we didn't know that there is a right solution possible/available, and we didn't have that much time to find out the 'right solution'.
Sometimes, we have that feeling that 'this' is not the right solution, but still, we apply it because we didn't have that much time to go for proper analysis. Even though everybody wanted the 'right solution' but when it came to 'estimation' and 'cost' we couldn't do much. Even though the team had very senior, competent, and experienced techies, nobody was in a position to come up with the 'right solution'.
In this type of case, there is no 'we will handle it later' approach because when we decide to apply some quick fix, we have already convinced ourselves that 'this is the only way out'. Therefore, we learn to live with this debt.
In the future, if anybody from the team comes across a better approach or even the 'right solution', we have to manage the schedule. Therefore, in this kind of debt, it is mostly racing against time with inadequate tools.
Environment-related Technical Debt (ETD)
In short: We know what to choose, but we can't.
We know the right solution, but the environment in which we are working is not ready for that right solution.
This kind of case can be mostly seen when the application is very old, but the requirement is quite modern. Apart from the schedule, cost also plays a significant role in limiting our ability to explore things as the cost doesn't allow us to add modern tools in our old system. The stakeholders are not in a position to wait until the system is renovated to that level.
Unlike KSTD, in this type in spite of knowing the right solution, it can not be implemented with whatever we have.
There is a sub-type in here - Sometimes, the system already is overloaded with previous technical debts that implementing the right solution is not possible anymore without a large cleanup project.
The only way out considered here is to renovate the system. However, instead of renovation, we take it as rewriting. We need to realize that renovating or even rewriting doesn't guarantee a total 'Debt-free software'.
Priority-related Technical Debt (PTD)
In short: When we 'choose' pleasant over right.
This type of technical debt is actually taken from one or more Software quality attributes.
For any software, there are two types of 'Critical Software Quality Attributes' -
Common Critical Software Quality Attributes (These are the basic quality attributes that each software must maintain to exist)
Reliability
Usability
Performance
Availability
Special Critical Software Quality Attributes (Special quality attributes are those quality attributes which software must maintain to exist apart from common critical quality attributes depending upon the requirements. The importance of these attributes depends upon the context and functionality of the software. The stakeholders are supposed to select the appropriate software quality attribute based on the type of software and domain)
Thus, when 'Time-To-Market' is considered more important than 'Performance', we are taking a technical debt from 'Performance'.
However, you must have observed that in every case of technical debt, it is a contribution of more than one attribute. We never take debt from only one quality attribute, there will always be some 'collateral damage'.
For example, along with performance, readability and modifiability are also reduced.
By now, we have realized that -
One debt forces us for the next debt and so on. i.e. Old PTD and KSTD force us for new ETD and so on.
Technical debt has more consequences than rework and impact on cost and schedule
Similar to all other debts, technical debt also charges 'interest' and it grows 'Fibonacci-way' with time. The older the debt, the higher the efforts required to pay it.
Every application has its own survive-ability under the technical debt depending on the age of debt and the quality attributes suffering from it. At this point, I don't have any formula to calculate, but it certainly impacts the life expectancy of the software.
There has to be some way to deal with the debt, right?
Well, debts are not bad things, unmanaged debts are ...
We must understand one thing that every now and then we all have to take new debt for different reasons, and it is neither bad nor avoidable. However, not fixing it; is bad. Therefore, my suggestion would be to record the debts and manage them.
Managing a debt doesn't mean living with it.
Accept that there are debts. This is the very first thing about any issue, that we have to accept that the debt is really there.
Record the debts. We need to be aware of the debts. Let us be realistic, there will be some debts which maybe we are not even aware of. However, let us list down all those we are aware of.
Revise their status periodically even if we are not actually working on one. This will help us to understand its current impact and will help us to decide its priority.
Don't expect one-shot kill all. We have to treat it like along with our all daily tasks, we have to invest some time and effort in fixing the debts. Even though there will not be any profit seen immediately, it will save a lot of effort and in the longer-term, it will be a very profitable activity.
Even though, this may look like 'Infinite defect methodology', please remember, this activity doesn't really encourage us to take as many debts as we want. No! it doesn't, it just suggests that we must accept that even if the application is working fine, there are some debts to be settled. It is unrealistic to expect completely debt-free software for the entire lifespan of that software.
Debts should only be taken when there is no other alternative. However, even if we are following all the stringent quality processes and even if we are following 'Zero defect methodology', we will still have some technical debts.
There is a fundamental difference between technical debt and a bug or defect is, debt doesn't result in 'incidents' in a shorter span while bugs do. Generally, debts will start showing their presence in incident reports only when the debts are so old that nobody remembers them anymore.
We have all the ways to identify and fix defects, but mostly we are reluctant to even accept the debts.
What do we do when we have (financial) debts? We estimate their impact on our resources.
We plan to reduce their impact by starting the payment. We even try some pre-payments to reduce the burden.
However, the most important part is we pay some part every month as EMI. Right?
We should do the same with the technical debts...
We should have a periodic process of 'Paying the EMI'. Keep in mind to have at least one JIRA per sprint to settle some small part of Technical Debt(s).
Keep your eyes open. Every time you are working on any code change, don't just think about your code, think about the entire code and record any Technical Debt noticed.
Remember, a thorough code review plays the role of 'Annual Medical Checkup' for your application.
This is just another way to 'Continuous Improvement' or 'Continuous Application Renovation', with a focus on fixing the debts. Thus, instead of going for a large cleanup project once a while when your application is almost on the death-bed, making it a continuous process makes things easier to handle. Like instead of cleaning the entire house for once in five years when it is impossible to stay there, clean it on a daily and weekly basis.