Techopedia defines technical debt (aka code debt) as a “software development concept that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.”
Just like financial debt, technical debt needs to be paid, otherwise, the speed of change implementation becomes so slow that any well-designed competitive software product can easily overtake your cumbersome and badly designed solution. In addition, it’ll eliminate the ability to accurately estimate development work and will lead to high staff churn rate as a result of a more stressed engineering workforce.
In many software development teams, programmers live from deadline to deadline and are pretty used to accumulating a huge backlog of uncompleted tasks or tasks that are kept to be postponed forever.
This article aims to answer the question of how to stop accumulating technical debt and will review this concept from both product owner’s and software developer’s perspectives.
Why tech debt is inevitable today
Over the last decades, we’ve been living in a paradigm where time to market is of paramount importance to ensure business growth and sustainability. It’s quite possible that by the time your software team finishes working on your next big thing in tech and launches it to the market, there will no longer be any devices able to support it. As such, technical debt is the norm of today.
When it comes to technical debt, it’s necessary to distinguish between the programmer’s desire to improve something in the codebase and the real business need to optimize or refactor code in order to avoid issues when scaling or changing functional and non-functional features and requirements.
Technical debt usually accumulates for one of the two reasons (or both):
- Lack of experienced developers in the team, and
- The wrong choice of implementation/development method(s).
The first can be solved by extending a software team remotely/offshore to access external pools rich in required skills and experiences as well as providing continuous on-job training and initiating mentorship programs. This can help bridge the knowledge gaps responsible for technical debt accumulation.
The second issue poses a much higher risk, as it can result in very expensive mistakes. If you rush to start coding without asking sufficient questions, evaluating all pros and cons, doing proper research and business cases review, you’re condemned to have your technical debt inflate like a balloon at the end of the day, and you’ll have to rewrite half of your code from scratch.
Therefore, in order to reduce the accumulation of technical debt, you need to develop a habit of getting completely immersed in the task, get as many clarifications from the product owner/tech lead as possible, study all test cases, define a plan for yourself (on a napkin) and only then sit down to write your code. In such a way, the process will take significantly less time, the number of bugs will be reduced, and the best way to implement the feature will be selected in advance.
The tech debt isn’t a bug or a bad source code; it’s deliberate neglect of the code quality or an attempt to create a kludge to quickly bridge some gaps in the codebase. Yet, writing the poor-quality code isn’t always the fault of programmers. There’re situations when you don’t have to commit the highest-quality code ever. For instance, when you need to build fast a prototype to see how your future solution will work or when you need to run a test app just once, you can’t often afford to write a clean and beautiful code due to time and budget limitations.
However, you need to develop a habit of cleaning your mess afterward. If you understand there’s no way to avoid the accumulation of technical debt, it is better to be prepared for this in advance and allocate time for “mess cleaning” in your time tracker software along with time for feature development.
Any software team will agree that tech debt is a scourge of any software development. It’s-nice-to-have-but-let’s-do-it-later approach is pretty common which explains why many Agile teams that work according to Scrum have endless backlogs.
How much project time should be devoted to tech debt elimination?
At 8allocate, most of our client-tailored teams work on Scrum, where PM or tech lead controls the processes and delivery, team size and composition, etc. All development work is done in bi-weekly sprints, with all tasks being divided into 3 main types:
- Product development: all tasks related to engineering, implementation and quality assurance (QA) of custom tech solutions;
- Support: tasks related to supporting and maintaining the client’s up-and-running products;
- Architecture: tasks for tech debt elimination (both from client and programmers’ perspectives)
Each sprint consists of all three types of tasks, with different timing being allocated for each type:
- Product tasks normally take 70% of sprint time;
- Support tasks consume 20% of sprint time;
- Architecture tasks take 10% of sprint time.
As we deliver a major milestone to the client, we hold a technical sprint within the team in order to define and prioritize the most critical tech debt elimination tasks. It helps relieve the backlog of extra task loads.
In our company, we keep all tasks for tech debt elimination in a separate JIRA project as well as in each client team’s individual backlogs. This allows both PMs and team leads to be on the same page by closing tasks that are no longer relevant or that have been fulfilled while solving other issues.
To effectively get rid of your tech debt, you can use the following methods:
- Allocate up to 10% of each sprint for tech debt tasks;
- Hold a technical spring at the end of each major project delivery to the client;
- Keep the tech debt backlog up-to-date and make your PMs and team leads accountable for this.
There’s one more approach frequently utilized by software teams. Developers simply don’t bother to deal with the tech debt until the product becomes completely obsolete and unsupported. After that, there’s always a series of conflicts between the software team and the product owner as well as attempts to get top management’s buy-in, and most of these situations are solved with the decision to rewrite the code and upgrade the entire legacy system.
How much is it to eliminate tech debt?
According to DZone, “applications carry on average $3.61 of technical debt per line of code”. For some reason, the average cost of tech debt elimination in Java apps is higher: $5.42 per line of code.
Here’s our fancy way of dividing tech debt cases based on their cost, from least to most expensive:
In many cases, eliminating tech debt becomes a very expensive venture, as the company usually has only two ways out and both involve a certain investment:
- Hire an in-house/onshore team of developers, architects, and testers, assign a PM/tech lead, improve infrastructure, purchase all of the necessary licenses, etc, which normally results in pretty high expenditures and overheads;
- Outsource tech debt elimination to a specialist 3rd party provider offshore/nearshore to access resource-rich locations, cheaper workforce, and better external expertise.
The second option is more viable for startups and mid-market companies that struggle to find, hire, and retain top software engineers, tech specialists, and PM resources. They’re at risk of generating an uncontrollable backlog of tech debt tasks while seeking talent for their debt elimination endeavors – a burden too heavy to carry that can break the company’s backbone.
By outsourcing code debt elimination, they can focus on their core competency and new business development, while having an experienced and resourceful partner replace their legacy software and refactor code. Today’s outsourcing provides two key benefits:
- Fast time to hire (up to 50% faster than onshore);
- Cost arbitrage
To conclude, the earlier you approach your tech debt and take measures to eliminate it, the smaller interest rate you’ll have to pay at the end. And what’s your take on this?
