Debt, At Its Most Basic Definition, Is When You Trade Getting Something Now For The Cost Of Interest
Even if you pay back your debt quickly, you’ll still end up paying more than you originally took.
If you don’t, then your debt will increase. If you choose to ignore your debt altogether, you’ll eventually go bankrupt.
This is a pretty good analogy for what happens when you write software either before you have a good understanding of your business needs, or in the hopes of saving time by taking a few technical shortcuts.
Fast vs Good
Technical debt begins the moment you start making any decisions motivated by the concept of “easiest to implement” rather than “best overall solution.”
[emaillocker]
The best overall solution to your technical needs usually takes longer to implement. In an effort to speedtrack operations, you might choose a shortcut or two, which is exactly when you start incurring technical debt.
Technical Debt is Not Bad Code
It’s worth noting that technical debt does not necessarily mean bad code. Bad code is bad code. Technical debt can (and often does) result from the work of talented programmers who are placed under unrealistic project or time constraints. As a result, they need to take a few shortcuts.
These shortcuts almost always require constant maintenance and improvements during the lifecycle of your business operations, or else they’ll become even larger liabilities down the road. In other words, your debt increases because, whenever you want to change something, somebody’s going to have to roll up their sleeves and deal with the mess in which your system was built on.
Managing Your Technical Debt With Refactoring
Most businesses experience some type of technical debt, either:
- Deliberate technical debt – Where you intentionally make compromises in the short-term, that you know you’ll have to clean up later, or
- Inadvertent technical debt – Debt accrued through poor practices, technology choices, or mistakes in design and implementation
Your goal is to minimize the amount of drag your debt has on business operations. The technological term we use for this is refactoring.
Refactoring is when you restructure your existing code and data on a continuous base, to avoid accumulating a level of debt your business simply can’t afford.
“If you’re not refactoring, you’re just building up an ever-increasing amount of technical debt that at some point in the future, you’re going to have to pay.” – John Shiple
By not addressing your debt, your business is at risk of suffering outages – where your systems go down – or being unable to develop new features or products, because your existing code base and data are not structured to handle scalability.
The most effective way to approach refactoring is to constantly chip away at your debt, similar to how you’d pay down the principal of your fiscal debts.
Should You Avoid Technical Debt Completely?
While debt tends to have a negative connotation, it’s not necessarily a bad thing. A little bit of technical debt can help speed development and deliver your product to market faster.
The real problem occurs when the debt is not repaid. So long as you implement a policy of refactoring – as part of your business operations – then accumulating a healthy balance of technical debt could actually benefit your business.
[/emaillocker]
