What are the consequences of prioritizing speed over quality in app development? And why do they always backfire when there is a deadline to meet? Check out our case study about how we tackled technical debt that was blocking our client from further business and software development.
According to Stripe, technical debt consumes 33% of software developers' work time. This cost increases as the product matures and gains complexity. Decreased engineers’ productivity and slower development are not the only consequences of technical debt. It also damages morale in the tech team, negatively affects the UX and overall user satisfaction.
In this article, we cover both, the theory and a real-world case study of technical debt management.
What is technical debt?
Technical debt is the outcome of prioritizing speed over quality in app development. Spoiler alert, at some point it has to be paid off with the interest rate (that gradually increases over time). Hence, code debt should always be a result of well-informed decisions. Unfortunately, in practice, it’s often a consequence of insufficient commercial experience, programming skills, knowledge about software architecture, or in the worst scenario, someone’s ignorance.
Technical debt examples
We often associate technical debt with old legacy applications and don’t realize that the debt appears at the very beginning of product development. It starts small, and over time it gets bigger, more time-consuming, problematic, and costly.
Let’s take a look at some examples of technical debt:
- Lack of tests
- Inconsistent architecture within a component
- Outdated dependencies and infrastructure in general
- Code or infra that is no longer used, but is not deleted
- Code not conforming to coding style
- Duplications of the same code with similar semantics, a.k.a. not centralizing knowledge
- Incomplete or lack of documentation.
Benefits of reducing technical debt
From a programming perspective, code with less technical debt is more reliable and trouble-free to maintain, modify, and extend. It also makes it easier, faster, and cheaper to retain impeccable performance in the long term.
Business-wise, a high-quality code translates to faster time to market for fully-featured products and reduced development cost of new features. With that in mind, it also requires doing things the right way from the very beginning, so first deliverables arrive slower than when prototyping.
For both, business and technical teams, better code means fewer and smaller unpredicted fires, more stability, and fester fixes.
Case study – the true cost of technical debt
Our client is an IT and marketing consultancy from Amsterdam. We had been working together for a while when they reached out to us with some code quality issues that one of their business partners was facing.
The partner operates in the leisure industry providing 6.000 hotels and their 960.000+ guests with tech and marketing solutions. The company’s software was developed super-fast and the engineering team had to compromise on quality, in order to deliver the application in time. It resulted in a sizeable technical debt that became problematic on many levels:
- The core business: Duplications in the price-defining code made it difficult to manage pricing and therefore accounting.
- Business development: When the company was planning to launch an integration with a new booking provider within a tight deadline, code issues were slowing down the process. On top of that, errors weren’t tracked properly, which made things even worse.
- Software development: The engineering team was frustrated as they were facing intense pressure from all sides, and were not able to deliver new features, as the environment was hard to set up, the development process was slow and inefficient, and they had no time to write tests.
How we tackled technical debt
Complicated as it may sound, many businesses face similar costs of technical debt. If you found yourself in a similar position – yes, it’s a reason to worry; no, it definitely isn’t the end of the world. There is a happy ending. Let’s see how we found it.
First, together with the client’s team we decided to stop further development of the old platform and limit migration of old data. On this ground, we were able to work on a new booking platform integration without thinking too much about the old code. The booking process was quite complex, so went for a DDD/CQRS approach to define the logic of the new platform and test it on the unit and acceptance level.
At the same time, we simplified the development process so that most of the PRs were merged right after a code review (on demand) and some followed a different process, where a PR is merged first, and a code review is handled later (we call it post-merge code review). Although it may sound quite risky, the site didn’t have any traffic at that point and the whole process was covered by tests.
As for the old platform, we equipped it with an error tracking tool, log collection, and tests for the most crucial business processes.
Results
We did meet the integration deadline! At the end of the process, we had to take some technical debt ourselves. But this time, it was well-documented and we knew where we could sacrifice quality in the short term. Once the feature went live, we handled the debt as a part of business tasks.
Using and maintaining the old platform is much easier and less frustrating after the improvements we made. At that point, the company’s software is fully functional and ready for further development.
Keep an eye on technical debt in your app
If our client’s story sounds familiar to you, wait no longer. It’s time to deal with your debt and save your business operations while it’s possible. If you need any help, get in touch, and let’s do it together.
To those, who are about to kick off the development of a new product – double check if you have software development practices in place, and whether your team is capable of delivering high-quality code. Also, make sure you are aware of the consequences of your decisions and understand what will result in technical debt, and how difficult it will be to address it in the future.
Drop us a line, if you are not sure about that. Working with a senior programming team that takes pride in high-quality, well-tested, and peer-reviewed code, will surely help you along the way.
