Technical Debt is a metaphor developed by Ward Cunningham that describes the consequences of bad software development practices. This could be bad architectural design, development of features without any automated tests, bad technology choices, etc. The debt itself is the amount of work required before a job can be completed. If not paid off, it will accumulate interest, making it harder and harder to function and implement other needed changes.
How does it happen?
- Technical Debt is often accrued when a business is interested in getting a product or feature released before all of the necessary components or related changes are in place.
- Sometimes a business isn’t aware that decisions being made could lead to Technical Debt until later, when changes are required.
- If a software developer simply doesn’t know how to write quality software, they may be creating Technical Debt as they are creating features.
- When there is a lack of supporting documentation for software code, the work of creating the documentation represents Technical Debt.
- Creation of software features without a test suite is also the immediate creation of Technical Debt because as the feature set grows, there is a higher chance that any future change may introduce error.
What to do?
The simple answer to getting rid of Technical Debt is the same as financial debt. Stop taking on new debt and double down in your efforts to pay off what you have. Little by little, you’ll get to a point where you are debt free.
Just like a credit card, Technical Debt can be valuable tool if used responsibly.
The problem is that most businesses are trying to make strategic decisions at the daily speed of operations. They incurred the original Technical Debt because they needed to get a product to market quickly, and they have trouble paying it down because they now need to support the product with further development.
Perhaps the most acceptable solution is to think back to your first credit card and the “responsible spending habits” your parents talked with you about, or the hard lessons you learned. Just like a credit card, Technical Debt can actually be valuable if used responsibly.
How to dance with the devil
Credit cards can be a great tool to defer payment until a later date. If you charge a purchase and pay it off as soon as you get your bill, you don’t pay any interest, and there is no debt. If you make a small purchase and let it accrue interest for a billing cycle and then pay it off, that’s not so painful either. Where you get shackled by financial debt is when you take on more than you can afford, so you are able to have what you want now, but not pay for it.
Much like credit cards, Technical Debt can also be used responsibly as a tool. If you need to get an initial product in front of customers without software tests or documentation, it may be acceptable to do that as long as you dedicate a period of time after delivering the software to add those things. You have to be responsible enough to gauge whether it is okay to accrue that debt, and to ensure it isn’t so large of a purchase that you’ll be paying it off forever.
Steve McConnell wrote a detailed blog entry about Technical Debt and the implications of not dealing with it:
One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges. If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., “servicing the debt”) that there is little time left over to add new capabilities to the system. With financial debt, analysts talk about the “debt ratio,” which is equal to total debt divided by total assets. Higher debt ratios are seen as more risky, which seems true for technical debt, too.
Perhaps a good rule of thumb could be to calculate the going rate for your software engineering talent, then track the hours spent on the project and estimate whether you’d be okay carrying that balance on a credit card.
I think it’s fair to say that it is nearly impossible or at least improbable for a modern software development team not to incur any Technical Debt. The key is to spend responsibly, and schedule time to pay down the debt. If you accommodate this up front, you’ll be much better prepared and positioned in the future.