How much money you lose with bad code
Nobody likes to lose money. Studies show that the same person is relatively less happy when winning €100 than sad if he or she lost €100. Taking this into account, it’s astonishing how much money companies waste due to technical debt and even do not realize that!
If your development costs are around €20 000 a month, and due to technical debt you waste 40% of the development time to fix bugs and issues - then you lose €8 000! Per month! This money could be spent on features and improvements, but right now, you have to pay for the technical debt you have. 40% sounds too much? I will perform some simple calculations later in the post and prove it to you.
In his recent post about technical debt, Piotr described this topic in more detail. In this piece, I am going to focus on the aspect of money. I want to show you how much you potentially lose by not paying back the technical debt, or in other words, by having bad code in your project
To make the topic easier to understand, let’s divide the expenses into four buckets. Each bucket is a different category of payment.
The four categories of cost generators are:
- Development (maintenance) costs
- Environment costs
- People (Human Resources) costs
- Customers (sales/marketing) costs
I will describe the possible issues and calculate the total cost of technical debt based on an imaginary product called BrokenPiper. BrokenPiper is 5 years old, and the MVP was built with a lot of technical shortcuts (that's what you often do while building an MVP). The product gained traction and is quite successful. The development costs are around €20 000 a month. The total monthly recurring revenue is €80 000, made out of 4 000 customers, each with a subscription worth €20.
| BrokenPiper basic business details | |
|---|---|
| Development costs/month | €20 000 |
| Number of paying customers | 4 000 |
| Subscription price | €20 |
| MRR | €80 000 |
Development/maintenance costs
Poor development pace
So the BrokenPiper team is starting a new sprint. They estimate tasks, agree on a scope and start coding. John, BrokenPipers best developer, picks up a task and starts his work. Code is delivered quickly, tested, and released. Users are happy, extend their subscriptions and the business is growing. Nice story, right? Right, but in 90% of given cases, it is not true because of technical debt. And this is also not true in the example of BrokenPiper.
The real story goes like this: The sprint is planned, John picks up one task. He starts to code, but then hits a wall.
Some existing code is not working as expected! It has bugs, it's hard or even impossible to extend etc. There are a dozen things that make the task way more complicated than foreseen. The developer has to go through the code, debug it, try to understand it, finally fix and retest the neighborhood of the altered code. Instead of one day it takes two or even three days of development.
This problem applies to new features, improvements, and even bug fixes. If you have bad code, then it's way harder to debug it and find the root cause of a bug. It’s also harder to fix it. I’ve seen such cases quite often. Bad code leads to many hidden dependencies. I’ve seen projects where one small change in one part of the system caused huge problems in a totally different part.
Slower development pace means that the maintenance is more expensive, applying changes takes longer and costs more, but there is even more behind this. Bad code brings in a lot of uncertainty to your planning. You miss deadlines. It is frustrating for you, and the whole team!
I’d say quite often 40% of the time is spent debugging and fixing existing code. And that’s probably a bit too optimistic looking at the projects we had the chance to review. I’ve seen projects that are spending 90% of the development time to fix bugs!
Why 40%? Let’s pick an example. In one of our projects there was a simple task. The objective was to fix a small issue with price calculations for products. The estimate was 4 hours as it required some changes in the old part of the codebase (written by someone else). When the developer started to work, it quickly came out that this will be a nightmare. The code was so embroiled that the price calculations were spread across 20 different files, it was a total mess and required manually checking each possible path in the calculations. Names in the code were unclear, the comments left were wrong. It finally took 20 hours to implement and confirm that change.
Cost summary for BrokenPiper:
40% * total monthly development cost
= 40% * €20 000
= €8 000/month
Security issues
Security issues are more common than anyone would like to admit. In fact, most of the software we helped to fix had some of them. Security issue are not used by hackers on the day they were introduced, but believe me - that day will eventually come, and when it comes it will be a total disaster. Bad PR, angry customers, broken NDA agreements. It will cost you a fortune.
There is one part that’s hard to understand for me regarding security issues: they are really easy to fix. It costs a fraction of the overall development costs, and still, most companies do not bother about fixing them! Why? Because they don’t know that they have such issues.
Unfortunately, security issues are hard to estimate, so I will skip them in my calculations.
Environment costs
High coupling
Bad code is almost always highly coupled with the technologies used. It’s just the easiest way to write software.
What does coupled mean? It means that the framework that you used, the platforms that you are based on, databases, maybe even operating systems and hosting providers are hard to switch and update in the future. Is this a big deal? Well, in your first year - no, in the following years? Yes!
All the external building blocks that you have used are now part of your system. They might have security issues, compatibility issues etc. Some of them will be updated and you need to adjust your code to newer versions. Some might get abandoned, and you should replace them. In a highly coupled system it is hard, sometimes even not possible.
What happens if you do not migrate? Well, you might have security issues, but your web application might also stop working.
Browsers get updates every week, and sometimes the changes are incompatible with the app you have. We had a customer where a minor Chrome update broke the used AngularJS version. What would happen if that Angular version was already out of maintenance and the migration to a new version would require months of work? That would be a disaster! Other project: Chrome changed the way cookies are handled by default. The backend was written using an old Symfony version. Time to update: at least a week of hardcore coding + a week of detailed testing afterwards. Just imagine: users are not able to sign in and you need two weeks to fix it! Thankfully we quickly found a workaround for this.
Outdated libraries and tools make it also harder to find solutions to problems you encounter, making the development pace even worse.
Poor performance
Quite often Accesto is asked to optimize code. Very often it is a couple of months too late, and the project is already suffering because of degraded performance. Bad code results in bad database queries, poor performance etc.
Most of the issues are quite easy to debug and fix, but when you do not do that, you just pay for more and more servers, CPU, RAM. To give you an example: Michał wrote a post about how he was able to improve the performance by 77% in only 4 hours.
BrokenPiper is using 4 servers, with a similar fix we could get rid of 3 of them and save €100 a month! Not much, but you can spend this on marketing instead, and customers will also be more happy with faster response times. You can read about a different optimization wins here: How to improve code performance in 5 steps?
Badly written code does not scale horizontally (for more info on this see Top 5 hacks to fix slow web applications). Apps that have bad codebase are often hosted on one machine. Same applies to databases. In such cases a single machine failure will bring down your whole app. I know cloud providers offer high SLA, but even with cloud the risk of a machine failure still exists, and if you offer SLA to your customers, that’s obviously a hidden cost.
Cost summary for BrokenPiper: hard to estimate because of the huge influence of outdated frameworks, libraries and platforms. I’d assume a development team needs at least two days each month to do small improvements connected to outdated tools. 800€/month
People costs
Bad code, lots of bugs, a lot of hardcore debugging, uncertainty when it comes to the results, poor development performance, outdated tools and technologies - all of this makes the team unmotivated. They hate their job.
Despite the common belief, developers sometimes go out to have a beer with friends. They go out and hear about the new shiny stuff someone is working on. This is often depressing for a developer. He finally leaves the company, and looks for a job that will allow him to work with newer technologies and better code quality. People rotation grows, new people come and leave every month. Effect? You need to hire new people all the time, then they require at least two weeks to learn the basics of your business and your codebase.
The worst case scenario I’ve seen was a company with 3 developers was able to keep each of the team members for only 3 months (or even less). So they had to bring new developers to the project each month!
In that company they had to spend two weeks each month on knowledge transfer and onboarding. This means €4000/month lost because of bad code!
You also need to hire new people, and I think I will be optimistic saying this is costing you €1000 a month in the described scenario.
Total cost for BrokenPiper: €3000/month (BrokenPiper has less rotation than the described project)
Customer costs
Customer costs are pretty hard to estimate in cash, but let’s give it a try.
You are not alone on the market, there are other tools that do the same job. This is called competition and it's great! But not always. It's definitely not great if you are drowning in your technical debt.
Bad code in this case means that you have more bugs. You also need more time to introduce new features, updates and fixes.
I’ve seen companies that need over two weeks to test a set of changes - even bug fixes - and release them to production! That's insane! A good development team needs less than an hour!
Customers complain about issues like bad user experience, reliability issues, but because of the poor development performance and the uncertainty in your development flow the agreed dates shift in time, and customers have to wait way longer and longer. This is getting frustrated and users leave.
Bad code influences your churn rate. If you improve your monthly churn rate by 2%, that will sum up to 24% saved each year! 24% of your marketing and sales expenses each year is „wasted” on filling this gap. Also, as your app is responding slower to the market needs (long time to market), some potential new customers decide to choose a different tool. That's even more money lost!
Customer support? More bugs and issues means more tickets, means more costs.
Total cost for BrokenPiper: 2000€/month.
BrokenPiper total monthly money lost due to technical debt
The total money lost each month in BrokenPiper is €13800! Sounds insane! That would allow hiring more developers or spend the money on developing other areas of the company. Almost €14 000 because of bad code, that’s the cost of technical debt in our example project. Sounds like an amount that can lead to bankruptcy right? €13 800 is over 17% of the total income of BrokenPiper!
€13800 monthly makes €165600 a year, you can easily buy a Porsche Taycan, and still have some money left!
Real life examples of technical debt influence on business
Let's take a look at two quite popular cases of technical debt influence on business.
Netscape
Ever heard about Netscape? If you are older than 30, you probably have. Netscape Navigator was the number one browser in 1995 with 90% of market share! Unfortunately due to issues with code quality the browser had to be rewritten, and if you read our article on why rewriting apps is a bad idea, you probably know that writing an app from scratch very rarely goes well. In this case it went horrible and Netscape Navigator lost the battle with Internet Explorer (95% market share in 2004). Netscape Navigator was shut down in 2007.
Knight Capital Group
Knight Capital Group was a company that used a high-frequency trading algorithm to invest money. In 2011, they had 1,4 billion USD revenue with over 115 million USD net income! 1418 employees on board. Knight Capital Group was the largest trader in the US, with a market share of over 17% on NYSE and most 17% on NASDAQ. Sounds huge right? And it was. But one day in 2012, one small bug in the code made them lose $460 million within 45 minutes!
I hope you believe me now, that the costs I described , even if hard to spot are real. There is one more important thing I need to mention in terms of the costs:
Debt spiral
When you have technical debt in your project, there are two ways to handle it:
- pay it back
- increase the debt you have
If you don’t manage your debt, each month you have more and more debt. In practice, this looks like this: code is bad and it makes both developers and customers angry, disappointed and unmotivated in the case of the dev team. Some of them leave your company. Now you need to attract new customers, and obviously hire new developers. No good developer will agree to work on a product that has no plans or possibilities to be better. You finally hire developers that are potentially less qualified than the ones that left your company. This leads to even worse code, the new developers are angry, and leave the company. The loop starts.
If, on the other hand, you pay back the debt, you might be able to attract better developers and make the codebase better. In such a case the spiral of debt will work the other way round and you will be able to fix most or even all the issues caused by technical debt! But you need to have a good plan to achieve that.
Suggested next steps
After reading this, you might still not believe me. Ok, I understand that - before doing the math myself I would never assume that the technical debt might cause such big loses. In this case I suggest subscribing to our newsletter. We plan to release a case study within the next few weeks.
If you believe me - start paying back your technical debt. If you are not sure how to achieve it - just drop me a message, and we can discuss your situation. You can also schedule a call with me, to check your current technical debt and how much money you potentially lose.
