Technical debt: what is it, and how do you pay it off?
Scott MorrisSolutions Engineer
Having been with 4mation since inception in 2001 while completing a Computer Science degree at UTS, Scott has played a variety of roles within the business through its almost 20 years of growth.
As a Certified AWS Solutions Architect, Scott has a strong ability to bridge the gap between the technical and business/user world. Scott has a deep understanding of the service we provide our clients having spent years as a Developer, Business Analyst, Team Lead, and Head of Delivery.
His focus now is heading up 4mation’s Internal Operations to make our work and suite of digital tools as efficient and effective as possible.
When software development teams build products, there’s always a risk of running into some technical debt. However, while the word “debt” can conjure up negative feelings quite quickly, tech debt isn’t as bad as it sounds.
What is technical debt?
Technical debt (or software debt) is a concept that measures the consequences of taking shortcuts during the software development cycle. When “time to market” is critical, software developers risk making less than perfect decisions that lead to extra work and additional costs in the future.
In this scenario, the development team is essentially taking a “technical loan” that has to be paid back with interest (at a later date).
While it’s something development teams should strive to avoid, it’s not always easy because of competing priorities.
When companies fail to address tech debt, they risk:
- Increasing the costs of maintaining the product
- Diverting critical resources from innovation
- Losing a competitive advantage in being able to move/develop quickly
- A negative impact on brand value and brand image
What tech debt is and what it isn’t
Although the definition is straightforward, there is some confusion. For example, some believe it’s the result of a lack of leadership, understanding, or insufficient experience – it’s not!
There are two types of tech or design debt. One is good, and the other is bad.
Good tech debt is intentional. It’s a conscious compromise between time and speed to build a Minimum Viable Product (MVP). In this scenario, you’ll almost always introduce some level of code debt (but that’s okay).
If your prototype proves your hypothesis, you’ll have an opportunity to develop the rest of the product based on end-user feedback. At the same time, you can deploy technical debt and refactoring protocols to improve maintainability and future performance.
Sometimes quality can be sacrificed to release new functions and features on time. But it’ll be critical to schedule time post-release to start measuring technical debt and a plan to remove it.
However, if the code is poorly written or architected and can’t be refactored, that’s not bad software debt, that’s a bad digital product.
Some common trade-offs include:
Lack of documentation
Documentation is at the heart of good software development practice. Whenever development teams focus too heavily on releasing and fail to write code that’s easily understood, nor documented, it’ll be difficult for new team members to join the project, hamstringing your future progress.
Parallel development
Parallel development is an extremely common form of good technical debt. However, using Version Control Systems to accelerate development with multiple people comes with the potential of added costs when code is merged ahead of a release.
Requirement clarity
When prototyping your MVP to attract funding, in an effort to accelerate development, startups tend to leave the non-functional aspects (like scalable performance, security, documentation, etc.) of the software for later. But the problem here is that you risk not being able to build it later due to non-functional restrictions (e.g. compliance issues).
Tightly coupled components
Tightly coupled components are notorious for making products harder to scale. In this scenario, it’s challenging to make changes to one area without impacting the overall code.
What should you consider before “going into debt?”
Regardless of what led to the code debt, it has to be resolved. Just like a loan or mortgage payment, it’s okay as long as you pay it back. After all, some debts or risks are necessary to achieve your end goal.
If you clearly define the criteria of the project, it’s not difficult to make a decision. You have to understand that your MVP or that rushed update is less than perfect. But it’s necessary to serve your immediate needs.
It’s not essential to write perfect code if it threatens to stifle your creativity. The same applies if it fails to solve immediate problems.
How do you evaluate the “interest” on tech debt?
To ascertain if it’s worth your while, ask yourself the following questions:
- Is it a fundamental part of your software?
- What’s the impact of code debt on future development projects?
- What’s the impact on customer experience and customer success?
- What is the increased risk it introduces to the system?
- What are the costs? How much time will it take?
The answers to the questions above will give you an idea of how much “interest” you’ll need to pay back. It’s also important to note that if you forget to pay off the debt on time, it’ll continue to accumulate over time.
This will have a roll-on negative effect on developers, budgets, and company resources. For example, when there’s a lot of technical debt, it can be demoralising for software developers because simple tasks can take days to complete.
In this scenario, you risk high staff turnover in the middle of a tech talent shortage. If your software engineers feel like their skills and talent are wasted working on your product, they’ll jump at the next opportunity that comes along.
How do you proactively manage tech debt?
Being proactive about software debt comes down to measuring technical debt regularly. Early detection and prevention help keep it under control while saving time and money.
If your developers are stressed and complaining about bugs in the system, it’s a problem that demands your immediate attention.
If they haven’t reached that stage, you can predict when you’re about to run into issues with code debt.
Here’s what you should look for:
- Developers are taking longer than usual to iterate features
- More developer hours are dedicated to fixing bugs than innovation
- Your product’s functionality and performance is poor
So how do you clear it and keep your project on track?
The best approach is to make time at the end of each sprint or each month to engage in code reviews to reduce design debt and refactor the code.
This process can also be outsourced successfully to senior software developers at an established augmented staff solutions provider. When they work cohesively with your in-house development team to review the code, you can pay off the debt quickly.
Like most things in life, going into debt is sometimes necessary to achieve your goals. Just like going into debt to go to university to get a better paying job that helps you pay the debt off quickly in the future, technical debt can be perceived as an investment.
If you’re smart about it, good tech debt will help you build your MVP quickly. It’s an approach that’s designed to focus on what matters most, so leverage it when necessary.
Get a technical assessment of the health of your digital system to identify strengths, risks, and areas for improvement.
Our Sydney-based team of experts run functional and non-function reviews to provide you with findings and recommendations to support your decision-making process. Request a call back now.
About The Author
