Technical debt is the work you're putting off in order to complete a job. If you're cutting corners now, saying "I'll get back to that later," you're incurring technical debt, and you'd better have a plan to manage it. If you're not making a conscious decision to take on technical debt and managing it properly, it will become unmanageable and lead to costly changes that could bring your organization to a standstill.
Given your current constraints, you might make a conscious choice to get into technical debt. That's OK. But it's not OK to carry that debt for a long time. As with any loan, technical debt compounds and will eventually come back to bite you unless you put yourself on a repayment schedule.
Know technical debt when you see it
Think of technical debt as a temporary compromise on the evolutionary state of your software architecture or development objectives. You're leaving some work incomplete, such as committing code without code annotations, making it difficult for anyone else to debug or change your work without trying to rebuild your thought process. Or perhaps it's that accumulating list of known defects that never get addressed. Or maybe you compromised on automated tests, which leads to more costly manual testing, escaped defects in production, or both.
Using outdated, unsupported, or deprecated technology for the sake of efficiency, or just because you're more familiar with it, also accrues debt. However, these risky examples don't usually involve software development teams. For the purposes of this discussion, technical debt involves reasonably incomplete work that's functionally usable while not adding significant risk.
Slippery slope: How technical debt accrues
Constraints happen in every aspect of life. You might not have enough money for a house right now, or you may be in a hurry to close a transaction, for example, so you go to the bank and take out a loan, with the understanding that you'll need to plan how you're going to pay it back.
The same happens when you're developing software. There may be deadlines for getting a minimum viable product out the door or meeting customer commitments, or you may have a temporary cash flow issue. As long as product management and developers are aligned, it's OK to "cut corners" for the sake of doing things more quickly, provided you do a risk/impact assessment and make a conscious decision to take that approach. There's a commitment being made here that the short-term debt can be paid at a later phase, while ensuring that there's a clearly defined and agreed-upon path to task completion.
Paying the piper: The consequences of technical debt
Let's say a team didn't put in place sufficient code annotation and testing automation by a given deadline. One developer started a module, but another must maintain it down the line. In fact, the initial developers will have to maintain their own code several months later and may not remember how or why certain things were done. Testing will be manual and costly, or you may only do partial testing. In the meantime, paying customers are using the software.
This leads to three key consequences:
- Slower delivery. As the business goes forward and usage grows, the cost of change rises exponentially. Poorly maintained code is hard to continue developing, which leads to longer development, testing, and deployment cycles.
- Higher risk. Once your software is used in production, every change can have an adverse effect on your customers and your business. This creates a tradeoff between short-term customer satisfaction and ultimate usability.
- Lower quality. With gaps in documentation and test coverage, as well as time and customer pressures, quality is clearly at risk.
Managing debt
Going into debt should always be a conscious decision, and one that you manage properly. When you optimally manage a financial loan, you minimize interest payments. Technical debt is no different. You can get started by focusing on these three dimensions:
- People. Foster a culture of responsibility and accountability across your product, development, and IT teams. Also, develop organizational awareness: Remember why you're in technical debt, where the debt exists, and how you plan to pay it back.
- Processes. Make it a habit to add any incomplete tasks to your backlog as soon as they come up, whether these tasks relate to documentation, automation, technology, or any other area. Visibility and discipline will allow you to prioritize and complete tasks efficiently and effectively.
- Technology. Put tools in place that give you visibility and let you control how you manage your technical debt. For example, you could use a reporting system that shows your code coverage, test coverage, technical debt-related tasks, and so on.
The code technical debt conundrum
If you have a significant portion of debt anywhere in your code, you may be thinking about refactoring existing code. However, there are cases in which refactoring won't address the issue, for example, when you're trying to resolve dependency on outdated technology or when a redesign is required. In cases like these, you may be better off discarding legacy code and starting from scratch. Also, if changes to the part of the code you're looking at can significantly affect its function, a major refactoring would actually add more technical debt. It's a tradeoff of costs and risks, but if you have the people, processes, and technology in place, you can make a conscious decision with accountability.
A complete rewrite might not be possible for a legacy project, because the debt may be large and the people who originally incurred the debt have probably moved on. In cases like these, even partial payment of technical debt can be beneficial, so focus on the critical modules. It doesn't have to be all or nothing.
Managing with debt
Like debt management, addressing technical debt demands a continuous effort; it's not a one-shot deal. At any point, you should be able to make an informed decision about whether to get into technical debt or not, and whether cutting corners is necessary given a deadline or other constraints.
Taking on technical debt is OK, so long as you manage it and pay it back as quickly as possible. The place to start is with awareness and visibility: You need to know that you have it, where it is, and how to manage it. Once that's established, determine when you're going to pay it back and then put the tasks in your backlog. In so doing, you'll avoid surprises down the road and be better positioned to compete.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
