It Shall Not Pass: How to Manage Technical Debt
Editor’s note: Oftentimes, technical debt is a sore spot of software development projects that negatively impacts software quality and a project team’s productivity. However, with the approach that Boris, CTO at ScienceSoft, features in this article, you can start mapping out your technical debt management strategy. And if you feel that your situation requires immediate attention, you may consider using ScienceSoft’s software development consulting services.
During our 35-year practice in software development and IT consulting, we’ve had a number of customers asking us to recover projects with technical debt that internal resources couldn’t cope with. We’ve also had projects handled over from other vendors who didn’t manage to control technical debt. And our experience in such recoveries shows that technical debt can be tamed with a set of principles set in place.
In this article, I’ll share what types of technical debt exist and how we manage technical debt (or altogether avoid it) in the projects outsourced to ScienceSoft.
ScienceSoft’s guide to technical debt types
- Imperfect code for the sake of expedited delivery
Software development teams incur this technical debt (or code debt) deliberately when opting for easier but not-so-perfect solutions that later have to be refactored. This can happen in projects with tough deadlines set, for example, to seize a market opportunity before competitors or prove the concept with less financial exposure.
Naturally, I advise against such a strategy regardless of whether you develop software in-house or hire a vendor. The need for rework will slow down the team and, consequently, software evolution, which poses risks to timeline and budget adherence. And if you postpone addressing code debt to deliver a new product version sooner, it’s likely to grow out of control. Last but not least, scratchy software can turn down users that could have been otherwise interested.
Considering that, I’d like to introduce another way out for projects with demanding deadlines drawing on ScienceSoft’s experience. You can develop MVP with fewer features but keep their quality high. To do this, you’ll need to involve a BA who can prioritize features and offer viable solutions considering complex business needs and market situations. This approach helps ScienceSoft set the dynamic pace of software evolution throughout the whole software development life cycle while the customer starts getting revenue already at the early stages of the project.
- Postponed modernization of legacy systems
Legacy systems drain a company’s resources. Unfortunately, they’re often a part of mission-critical applications in the company (for example, CRM or ERP), so their modernization is a major deal with many inherent risks. That’s why modernization gets put off and accumulates more and more technical debt.
Based on ScienceSoft’s practice, modernization requires targeted expertise and the amount of time usually unavailable to allocate from the company’s internal resources. In such a situation, hiring a mature vendor allows eliminating code debt faster and more efficiently as they can offer a non-standard but cost-effective solution.
Let me share an example. In the project on modernizing business process modelling software, ScienceSoft’s team chose continuous refactoring (rewriting code) instead of commonly used parallel refactoring (creating new code and deleting legacy code after, which is safer but longer). This approach maximized gains out of the customer’s existing investment in software, reduced integration overhead, and streamlined the process.
- Bugs to be fixed as an inevitable process of software development
Alas, no software is faultless. A low to moderate level of bugs is a natural process in software development. And it’s not a serious obstacle if managed timely and if the trend is positive (fewer bugs as software evolves). For example, we aim at eliminating at least 90% of bugs in features before a software release. To do this, we implement the strategy described by my colleague Andrei Mikhailau in the article on software quality, and use key principles discussed below.
How to manage technical debt: ScienceSoft’s recommendations
I’d like to introduce the approach we at ScienceSoft follow for technical debt management. I recommend considering it for software development projects of any complexity to improve efficiency and reduce stress related to dealing with debt.
First of all, our project managers and technical leads take action to reduce technical debt and then measure it to ensure the project is moving in the right way. Then, we create a working environment productive for eliminating technical debt. It’s built on the following management principles:
- Importance. We prioritize tackling technical debt with the same value as any other development tasks. We make it a part of our project roadmap, discuss it at team meetings, and explicitly allocate time resources for addressing it.
- Visibility. We keep work related to technical debt in the same backlog as new feature work. I don’t recommend using a separate issues tracker for it as technical debt may slip out of sight then and seem more dreadful to get down to than it really is.
- A gradual approach. Although some vendors choose to set apart the whole day or even a week for dealing with technical debt, we prefer to eliminate it in small chunks throughout the iteration. In such a way, we make it a habit and avoid overwhelming the team.
Reinforce control over your project
Although technical debt, or code debt, is inevitable in software development projects, its harm can be minimized with a proper management approach. I recommend making technical debt explicit, discussed and planned to be continuously worked on the same as other parts of the project.
And if you’re stuck already, first you need to identify what are the blockers that make technical debt accumulate. Most commonly, they can be found in planning (chosen architecture and technologies), the development process or team organization. If you think you need a helping hand on detecting and mitigating existing problems and risks, feel free to write to us and request our consulting services.