Technical Debt - The Number One Reason Why Software Development Projects Get Derailed

A couple of years ago we had a very successful product - a game hosting management panel. Over the years our client database grew and we introduced support for new games and new features.

That was our first product, and it became quite popular. At one point it was used by the majority of game hosting providers in Poland.

But then, here’s what happened: as our client database quickly grew and we extended the application’s functionality, we consciously started taking shortcuts. Sometimes because of time constraints, other times we just thought it was the smart thing to do.

With time it got harder and harder to fix the bugs and introduce new features. We had been adding fuel to the fire without noticing it. And then, one day, we just realized the product was not profitable anymore due to its technical debt. The expenses of maintaining the product outgrew the profits it had been bringing in.

(I hope you don't mind some self-mockery.)

The wheels fell off our success and we had to make the tough decision of ending our beloved product’s life. Just imagine, having the majority of a national market as your client, and not being able to earn any more money.

This situation had taught me something - skimping on quality always costs an arm and a leg in the long run. In my new projects, I now realize there is no place for such shortcuts. The phrase ‘technical debt’ is still something that gives me chills.

WAIT A SEC. WHAT DEBT ARE WE TALKING ABOUT?

Technical debt is not a physical thing, it’s a metaphor developed by Ward Cunningham that helps you think about the problem behind it.

Technical debt means that some parts of your system were made the “easy” way without taking care of the quality of the code written. Keep on cutting corners and your technical debt will likely grow. Like financial debt, it incurs interest payments - you don’t just pay back what you owe, but the more time you take, the bigger interest payment will be. The only difference is that no one comes out profitable from this situation - except maybe for your competition.

WHERE DOES THE TECHNICAL DEBT COME FROM?

So why do developers introduce technical debt? There are several reasons. I will be honest with you the first reason isn’t so pretty- some developers introduce technical debt because they are lazy and they choose the easier way to introduce a functionality.

At other times, there are junior developers who are not exactly aware of what they are doing or they lack certain skills. That may also lead to a technical debt or even a total mess- which is even worse than technical debt, but that’s another story...

A situation in which features consciously need to be implemented in a fast and cheap way is also common in the industry when the first-to-market strategy is used. Although it perfectly fits current business needs, one should remember, the faster the loan is paid back, the less it costs you in the future. The sad truth is, too few actually pay it off quickly, procrastinating, until it is too late.

IS THERE TECHNICAL DEBT IN MY PRODUCT?

Answer these questions to find out:

• Is the development slowed down?
• Are there any breakages and outages?
• Do the same bugs return?
• Does the time of implementing new features constantly increase?
• Is your software product working slow?
• Are your software developers reluctant to work on the project?
• Are your programmers escaping from the company?
• Did you push your development team to implement new features faster than they estimated?
• Did some weird bugs appear that were very hard to reproduce or fix?

If you answered YES to any of the above questions, then you most probably have too much technical debt in your project. Keep in mind that these are only examples.

Regardless of whether you are aware of the debt or not, you can be sure that if you own any kind of software you also own its technical debt. It is very often the elephant in the room, no one wants to talk about it.

HOW MUCH DEBT DO I HAVE?

Here is the bad news - technical debt is rather unmeasurable. There are some ways that can help estimate the amount of debt, but they are only poor estimates that do not have any connection to real world. Such estimates can only help to compare the results between different versions of your system. There are tools that help to estimate the amount, but that’s a topic for another article.

DOES TECHNICAL DEBT INFLUENCE MY BUSINESS?

Yes it does, like any other debt. Not only you have some code that needs to be refactored (and you need to pay developers for it), but what’s more important- the more technical debt you have the longer it takes to introduce new features. In other words, technical debt slows your ability to deliver future features. In some situations it is so big it is not possible to introduce new features in a reasonable time and within a reasonable budget! In some cases, the whole development can get stuck and no new features are added.

Just imagine being stuck while your competitors are gaining advantage with every day. Painful, right? Fortunately, not all technical debt is bad for your business, and thus not all of it has to be paid back. You just need to keep it on a low level.

Some very terrifying examples of a disastrous influence of technical debt might be Friendster and Knight Capital. Friendster might be the first social network ever, but it lost its chance to win the market due to technical debt issues - page loading times were too slow, and the service was not able to scale quickly enough. At Knight Capital they lost $440 million in 45 minutes just because they had old code still installed on their servers, and the code was not enough tested. You can find a lot of articles about this case as it caused major disruption in the prices of 148 companies listed at the New York Stock Exchange.

WHAT SHOULD I DO?

As I mentioned before, it’s hard to say how much debt you have and you should probably just ask your developers about it. Hopefully, they will not beat around the bush and will be very direct with you. Maybe they are already?

The best way to fight technical debt is to build a shared understanding of it, and to change the team’s philosophy. Very often the most important step is the first one you take - right now you are already aware of technical debt and if you decide to fight it - you are already on a good path!

• Try to educate yourself - I know you have started already since you read this article. Your product owner and the whole team should also have an opportunity to learn what technical debt is and how it influences the business. Bring awareness, and talk to your team to try and find the most optimal solution. It is important that the team understands what the debt is comprised of, how to identify it, and then how to tackle the problem.
• Create a process together.
• Modularize your application into smaller logical parts that can be refactored separately.
• Pay attention to code quality, write automated tests and save enough time for refactoring.
• You can also save a special day each week/month for refactoring/decreasing technical debt. Give it a fun name and introduce some interesting rules. Maybe order some pizza and let the team discuss the most important issues first. Then work on them together.
• Once again: let your developers write automated tests each time someone finds a bug (a test that documents it). Try to add tests before you implement new functionalities (Test Driven Development approach).
• Do not push your team to quickly deliver new functionalities if there is no good reason for it. It is not always worth it to release a feature one or two days earlier just to have it without any strong business need.

KEEP CALM...

I have experienced the devastating influence of technical debt in my own experiences and I have seen companies struggling with it and seeking for help. Unfortunately, it’s such a common problem that if I would write down all stories about technical debt - it would be rather a book than a blog article.

But don’t lose your hope - there is almost always a way out. You just need to take the first step and point your team into the right direction, and keep heading towards the light at the end of the tunnel. My suggestion is to take the first step, even if it’s a baby step today.

If you are interested in this topic subscribe to be the first one to read the next part.