What is technical debt and should you be worried about it?
If you have a software product, you may have heard of Technical Debt but do not understand what it means. If you are worried about Technical Debt and want to understand more about it, this article is for you.
In this article I describe how I see Technical Debt as an advantage and why you should not try to avoid it but manage it to your advantage.
What is Technical Debt?
No matter what you are building, decisions will be made that trade-off time to market against quality.
Developing a solution that is likely to meet future needs, efficiently, effectively with low defect rates takes time and effort. In the short-term, it is far quicker and takes less effort to develop a solution that meets the immediate needs that is effective for the number of users you have today.
All debt has to be paid back
Like any debt, Technical Debt has to be paid back.
As your development continues, the number of compromises made increases along with the Technical Debt. The cost of further development rapidly increases due to the earlier compromises and a point comes when the level of debt becomes prohibitive.
At this point, large scale redesign or refactoring is required to allow development to move forwards.
This is the payback for the Technical Debt.
The knock-on effect of Technical Debt
The point at which Technical Debt has to be paid back can come as a surprise. You ask for what you think is a simple feature and the estimate for the development comes back as many weeks.
When you reach this point, the impact can be profound. All feature development and even defect fixes may need to stop as the whole solution is ‘re-wired’. This pause in development can range from weeks to a months.
Not only does the development roadmap get delayed but the quality of the product can reduce. The large scale changes that may need to be made to the software and to the underlying data structures can introduce defects that cause the product to become unstable.
Following the redesigns, there is generally a period of defect fixing that will further delay new features.
Don’t avoid Technical Debt
It may be tempting to try and avoid Technical Debt but, like like a credit card helps with cashflow, so does Technical Debt.
If you avoid Technical Debt, all features will cost you more in time and effort as your developers attempt to create the ‘perfect solution’. You may avoid the major refactoring required to pay back Technical Debt but you may face missing the market, which can be equally as expensive.
So, like the credit card, Technical Debt allows you to move quickly, be responsive and deliver what the market really needs in those early years of being a start-up.
In addition, if you do go down the ‘perfect solution’ route, you will probably also end up with Technical Debt as, especially in the early years, you will not understand your product we’ll enough to build the ‘perfect solution’. You will probably end-up building something that is not fit for purpose, requiring the same level of refactoring.
Conclusion
Technical Debt allows you to be nimble and responsive to the market needs. Like all debt, Technical Debt needs to be paid back.
Payback comes in the form of development delays whilst previous compromises are undone and refactored.
Like all debt, Technical Debt serves a purpose, allowing you to get to market more quickly.
And like all debt, you should always keep an eye on the level of debt being accumulated. Your development manager should be able to advise you. Expect periods of refactoring to allow your development team to pay back the debt. If you don’t, the cost of new features and maintenance will increase significantly.
Originally published at https://requillion-solutions.com.au.
