Technical debts are easy to accumulate, but hard to clean up. Another pitfall is that it’s difficult to estimate their costs and as a rule, it takes more than expected to pay them off. This article is a warning and a bit of friendly advice on how to avoid the avalanche of tech debt.
What is “technical debt”?
The term technical debt has agile roots. It comes from the comparison that Ward Cunningham (1) (one of the authors of Agile Manifesto) used to describe poorly written, low-quality, hard to understand code which creates obstacles for further modifications.
Comparing cruft to financial debt isn’t only a nice figurative pun. It conveys a very important message: the longer you neglect your cruft, the higher the interest rate you’ll need to pay in the future. In this sense, any extra effort that it takes to add new functionality to the existing buggy/low-performing application is the interest paid on debt.
Is technical debt always a bad thing?
In general, it’s a normal practice to postpone some internal refactoring/improvement works for the sake of delivering new features to market faster. In this sense, technical debt is a powerful management tool. In times of fierce competition, businesses have to compromise temporarily on quality of code not to lose users or other opportunities. Those who’re seeking for technical perfection, rather than building the right product, go out of business. That’s a reality.
Problems appear when accumulating technical debt becomes a habit, developers cannot keep up with new demands, and no one takes care of paying off the old debts. Small compromises and promises to get back to this smelly pile of code overgrow with new difficulties. Every new modification takes more and more time and keeps impeding the system, like an avalanche. As a result, the product’s code obtains infamous “legacy”, becomes obsolete and pulls businesses to the bottom.
And yes, it’s THAT dramatic.
LinkedIn had to freeze their new feature development in 2011 (2). Twitter had an emergency server switch which led to a three-fold decrease in search latency. Dodo Pizza faced feature development freeze for a year and lost over $1.5 mln (3). Technical debt, apparently, is the reason behind why it took Microsoft five and a half years (!) to move from XP to Vista. Reddit got into the center of a big scandal in 2015, after their newly implemented automated moderation bots missed many inappropriate posts due to picky behaviour of the legacy code piled on their website.
Other big companies, like Instagram and Research in Motion (creator of the Blackberry smartphone), are also among technical debt’s victims. And the list of such cases is ongoing.
These companies had to take tough measures and allocate tremendous resources to avoid the catastrophe and get their systems back on track. According to Stripe and Harris Poll report, companies lose $85 billion worldwide in opportunity costs annually due to dealing with “bad code”. That’s the price of poor technical debt management.
This sounds horrible, but there is also good news. Negative effects of technical debt in project management could be prevented by regularly paying it off.
It’s easier said than done – you might think? Indeed. The issue is complex and requires balancing the business interests first of all. However, there are some practical tips to keep technical debt under control.
Tech debt management: keep it under control
Be aware of it / communicate it
We talked previously that technical debt occurs when companies deliberately compromise on internal code quality for the sake of market prey chase. But this is not always the case.
Sometimes technical debt appears unintentionally. And then it’s even a bigger problem because you cannot control something you’re not even aware of. To avoid such situations we should always strive for professionalism, strong coding culture and honesty within the teams.
After you make sure there are no “surprises” hidden in software other than you know about – don’t rely on keeping it in your head. Keep track of it in writing, try to measure it, perform technical debt assessment, and update this data regularly. Make sure that all stakeholders are aware of it and know what measures are there to take to manage technical debt, as well as the repercussions of not dealing with it.
Practice code reviews religiously
It’s an easy habit that has a big effect on the quality of code, simply because two heads are better than one. It’s important though to make sure that developers really put effort into reviewing each other’s work and not treat it as another bureaucracy element.
Take advantage of automated tests
Another good habit that has many positive outcomes, one of which – preventing cruft from accumulating. But it’s not only a good thing to have. Those teams who neglect automating testing, tend to create more complex, prone to bugs code. So enjoying automated tests’ advantages must be a no-brainer solution.
Deal with it: refactoring vs. rewriting vs. leaving it alone
When it’s finally time to think about how to manage technical debt, there are several options:
1) You can leave it alone if it functions and no modifications are expected.
2) If the software is supposed to be expanded and modified – you can refactor it or rewrite from scratch. The latter is usually very tempting among developers who used to cry over this smelly code and we can understand them. However, as a rule of thumb refactoring should be preferred in a majority of cases. We’ve rationalized all the pros and cons of refactoring vs. rewriting for you in one of our previous blog posts.
* * *
We hope that you enjoyed your reading. If you have any comments or questions – don’t hesitate to contact us.
Recommended links:
- Check out Ward Cunningham explaining technical debt term here: https://www.youtube.com/watch?v=pqeJFYwnkjE
- Read more about LinkedIn crises caused by technical debt and how they dealt with it here: https://www.linkedin.com/pulse/when-your-tech-debt-comes-due-kevin-scott/
Read about Dodo Pizza technical debt management case study and great lessons learned description here: https://habr.com/en/company/dodopizzaio/blog/447154/
