What is Technical Debt?
Technical debt sounds like something you’d read about in financial magazines, and to be honest, that’s not too far off. This concept posits that sometimes completion of necessary parts of a technology project is delayed due to budget, or timeline, demands. When a project has to be quickly completed and delivered, despite the code not being perfect, your team is assuming technical debt to meet the deadline. This is not unlike how businesses incur debt to win a big client, expand their operations, or position themselves at the forefront of a new market opportunity.
The Software Engineering Institute at Carnegie Mellon University says that technical debt “conceptualizes the trade off between the short-term benefit of rapid delivery and long-term value.” To use a colloquial phrase, you rob Peter (your business’s future performance) in order to pay Paul (meet the demands or deadlines for delivering your project).
Martin Fowler, a British software developer, author and international public speaker on software development provides this introduction to technical debt:
“In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.”
Not all debt is bad, and if incurring some technical debt helps your company achieve a big goal, then it could be worth the “interest payment” of a more difficult task of future software updates or adding new features. With the move to Lean methods of software development, and with get rich quick stories about entrepreneurs rushing out product, many companies have decided that the risk of technical debt is worth it. But problems do arise, and what may seem like minor annoyances now often become major issues if left alone for too long.
Here are 5 ways that technical debt impacts your business:
Reduced Forward Motion
The problem with technical debt is when it gets out of control and development teams spend the greater part of their time paying off the “interest payments” from past projects, instead of working on new features or critical new updates. The technical debt must eventually be repaid and that comes at the cost of adding new features or working on other updates that move the product forward. Progress becomes stagnant. Instead of tackling new change requests, the development team spends hours, maybe days, even weeks, wrangling the quick-and-dirty code to get the product to a state in which future modifications won’t be a painful effort or crash the system.
Poorly Designed Code
If taking the quick and dirty route to reach a deadline, developers could skip the traditional protocol of writing clean, organized, code. Thus, the code structure would be messy and with potentially low readability.
Some red flags of poor design are:
- Using a code style once and not repeating the same behavior throughout
- Leaving out descriptive names for each of the modules
- Loosely stringing together code modules
These design practices may help get the project completed in time, but will make it challenging for different programmers to work on the project in the future. The technical debt associated with poor design will be a backlog of items related to cleaning up the code.
Pushing out a not-quite-perfect product could be a boon for your business, but it could also have challenging consequences. The technical debt associated with a product displaying volatile performance is related to fixing bugs, system crashes and engineers’ bandwidth. Bugs in the code might surface after release of a fast production, thus incurring technical debt to fix them. If your engineering team is spending large amounts of time implementing simple enhancements in one module of code, or they’re requesting schedule extensions, you’re incurring technical debt to fix an area of hastily written code. And, if your system crashes due to high volume traffic or editing of code, then you’ve just added to your technical debt to figure out the cause.
Technical debt will drain your productivity, leading to slower and slower output. Poorly designed code will require more of your team’s time and effort to decipher and manage. If you ask your team to make a simple enhancement to the code that would normally require 3 weeks of time, you might be surprised to learn that it’ll actually take them 6 weeks and they’ll have to postpone other projects. Technical debt will not only lead to your team slowing their build times, but also to a slowing of your overall production-test-release cycle. You’ll request new features, but such changes will add new bugs to the poorly written code and make it all the more challenging for your QA team to test. And, when you finally navigate the code and are ready to release, your team will probably be stressed due to the extended schedule and you will have most likely incurred profit loss due to the lost time on the market.
With an impending launch deadline, the QA code testing team will be forced to speed up their process and possibly miss tests, or swear to solve them later, and technical debt will be incurred to eventually go back and carry out the skipped tests. This has a negative impact in that you’re releasing code that has been rushed through testing or only minimally tested.
As the old adage goes, you get what you pay for. If it means taking advantage of a huge market opportunity, incurring technical debt may sometimes be the optimal decision. But problems arise when the amount snowballs into a behemoth, which can drain your resources. Too much technical debt can reduce your team’s agility, produce poor quality code, strain your testing team and eventually reduce your company’s overall productivity. Think of technical debt as a tool with the power to make or break your product release cycle – understand it, use it, and manage it with a long-term view. Our team has years of experience helping clients dig themselves out holes caused by technical debt. Contact us to learn the best practices for managing technical debt, or get in touch so we can help your team catch up.
Latest posts by Orion Jensen (see all)
- How Long Does it Take to Build a Custom Software Solution? - June 7, 2018
- Why a Code Audit is Critical Before Buying or Selling your Business - May 29, 2018
- 5 Ways Technical Debt Impacts Your Business - May 8, 2018