Technical Debt
What is Technical Debt?
Optimally we want our software to be efficient, have full code coverage, use the latest libraries and make it future proof so we would never ever need to look at our code again.
But in reality, that’s not the case. When we’re in the development phase we often face time constraints to meet the deadlines, sometimes we’d need to work on an older module that might be using outdated libraries, or there can be some design constraints or technological constraints, etc.
Due to these constraints, we aren’t able to write the most ideal code we would like to at times. We might take some shortcuts that may compromise code quality, cleanliness and sometimes efficiency as well.
These shortcuts would require some extra efforts in the future refactoring, thus known as Technical Debt or Code Debt.
In other words, it’s the outcome of prioritizing speedy delivery over perfect code.
This is often the case with fast-growing startups where speedy delivery is of immense importance and sometimes decides the fate of the organization, especially in competitive markets.
Development time is much more expensive in the early phase of development than later on.
Tech debt can broadly be termed into three categories:
- Deliberate:
Often engineers will know there’s the right way to do something and the quick way to do something. In many cases, the quick way is the right way (to avoid over-engineering), but at times the team will intentionally do something the “wrong” way because they need to quickly deliver the product to the market. - Accidental/Outdated:
As we deliver to the market we learn new things, requirements change and as time goes some libraries we rely on might get outdated and we’d need to update our software. If we design our Software well from the start we can resolve most of the issues with a little refactoring. But sometimes we’d need to go for a full-blown refactor if something fundamental changed and our existing design is not able to accommodate it.
Even Programming languages change and evolve over time, best practices change, new libraries come up which replace the existing ones and so on. We’d need to take these into account otherwise we’d end up with a lot of compatibility issues. - Bit-Rot:
It usually happens when we make small incremental changes with time that might be done by different developers who’d not have a clear idea of the design/logic which was originally intended. So we end up with inefficient and messed up code and readability decreases.
It's not a MESS
Oftentimes developers confuse the term Tech Debt with messed up code. Tech Debt is mostly a conscious decision and we know we’d need to address these issues in the future.
In an impassioned post, a long-time software development consultant, Uncle Bob writes “A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational. It’s always based on laziness and unprofessionalism and has no chance of paying off in the future. A mess is always a loss.”
Shaun McCormick’s definition of technical debt focuses more on the consequences in the long term, “I view technical debt as any code that decreases agility as the project matures. Note how I didn’t say bad code (as that is often subjective) or broken code.” He suggests that true technical debt is always intentional and not accidental.
Is it bad?
The answer to it would be yes and no.
Just as a financial debt can help an individual or an organization reach its goals faster. But it would need to pay interest payments for the borrowed money. As long as it has enough cash flow and assets to address the interest payments and future expenditures, it’s not an issue.
Similarly, a Software company can incur tech debt for the quick rollout of a feature or a whole application, which would require some extra efforts for future refactoring of code.
Not all technical debt is bad, and managing it well can yield tremendous benefits for your company.
“Software companies sometimes deliberately incur tech debt to reduce time to market.”
But just like financial debt, you have to be wise about incurring tech debt. Over the long term, accumulated debt can slow future refactoring, cause developer morale issues, or even sink your business entirely.
How to handle it?
Handling a tech debt can be quite a tedious task if we are not keeping a track of it.
According to a survey, US businesses are bleeding $6000/second trying to maintain their code. On average companies spend 28% of their budget on addressing tech debt.
The majority of IT leaders identify technical debt as a major threat to their companies’ ability to innovate. Thus handling tech debt becomes a crucial task for any project’s sustainability.
Below are some tips to manage tech debt effectively:
- We can greatly diminish the tech debt in the beginning stage by giving a deep thought and spend a good time on System Design before we start coding right away.
- Regular code reviews and peer-to-peer reviews (avoid bit rot)
- Boy Scout Rule: Leave the code in a better state than you found it.
- Set some standard set of best practices that the team adheres to and the entire team should be responsible to maintain the quality of code
- Make your tech debt explicit and consider this as an actual task that would be added to the backlog. Always think through the dependencies across modules, database layers, etc. before start working on it.
- Make it a part of regular sprints
- Count the number of tech debt items and if they’re higher than regular tasks perhaps you should prioritize working on resolving them.
Conclusion
Context matters a lot while defining whether Tech Debt is good or bad. Business Executives should be aware of the trade-offs involved and their consequences.
In general, Technical Debt is much less visible as compared to financial debt, thus it is easily ignored. Measuring it depends a lot on the perspective, the stages of development and can be quite subjective.
It's not problematic until it is.
