What is technical debt?

It has a lot in common with financial debt, hence the metaphor. In simple terms, if you want to buy something that you can't afford at the time, you take out a loan, which increases your debt. Similarly, in software development, if you want a feature to be implemented immediately by the development team, but you don't have the development resources, the team may be able to deliver that feature, but it will add to the - so called - technical debt.

To make technical debt more tangible, imagine that you want to build a skyscraper. A modern, solid, everlasting structure. You have a tight project plan with strict deadlines and the construction team is doing its best to make the plan a reality. They know it's not going to work, but they find a way to get it done on time and on budget by - let's say - not doing the plumbing right now. The foundation does not need plumbing, so the plumbing is put off until later when there are more resources. In this case, not building the plumbing is a technical debt.

So why is it a problem? Actually, there is no problem with technical debt per se, but it can grow into a project-eating problem - think of the crocodile.

Why technical debt can kill your software project?

Going back to our skyscraper metaphor and the worst-case scenario, the construction team doesn't tell you that they didn't do the plumbing yet. In fact, they have completely forgotten about it because they have been so busy trying to stay on schedule. Eventually, the skyscraper is finished and looks great, and you are happy because everything came in on budget and on time. But when the first person has to go to the bathroom, you can imagine what happens. And you can imagine how expensive it is to do all the plumbing work in a “finished” skyscraper.

This is a worst-case scenario, and there are processes in place to prevent or at least minimise such errors in the construction process. The same is true for software projects - but there are real-world examples of poor quality leading to technical debt that has had disastrous effects on both building construction and software development projects. We need to manage technical debt properly.

So it might have been fine to put off the plumbing for a few weeks when the foundations of the skyscraper were being built, but putting it off and then forgetting about it ultimately led to disaster.

You may have seen this diagram before. It illustrates the cost of change in software development. The later you discover a bug, or the longer you delay features or improvements that are essential to the project's foundation, the more exponentially the effort and cost increases.

What are the signs that you need to act quickly?

It is not always easy to spot, but there are signs that very often give you an idea that something is not quite right. Don't ignore that feeling, because ignoring it will only make it worse.

From time to time, we get requests to help save a project where the following indicators have been ignored for too long and the technical debt is overwhelming. And some of these projects have unfortunately had to be shut down and started from scratch, because there was no way to save the project for less than the cost of a complete rewrite. Although this is rare, it does happen, and I am sure you want to avoid it. So let's focus on the indicators that can prevent the worst and then I will give you tips and tools to help you get your project back on track.

Regularly missing deadlines

One of the most obvious signs is that new features or changes are taking longer than expected. The larger the project, the slower new features and changes will be implemented. Don't blame the developers, this is usually the result of many different factors and roles involved.

Features break too often

Another indicator is that new features break other existing things. This, in turn, leads to more time and effort needed to fix them and implement the new feature.

Lacking motivation

An indicator on the emotional side, the enthusiasm of the developers working on the project or on new features often fades

The root cause for technical debt

Before we look at how to manage technical debt, let's understand the core problem. In our experience, and as irrational as it sounds, most people don't like to admit that they have debt, whether it's financial or technical. As a developer, you don't like to admit that you couldn't implement a feature on time and in the right way. As a project manager, you don't like to admit that you can't meet a deadline. And as a CEO, you don't want to tell the press that your shiny new product has been delayed.

So the most important thing to do to prevent technical debt from leading to a project totally failing is to manage it proactively. There is no harm in being financially or technically in debt, as long as you are aware of it, can act accordingly, and are able to pay the resulting interest (be aware that it grows exponentially with technical debt).

How to manage technical debt properly

Managing technical debt in a software development projects is related to quality management, company and team culture, requirements management, and project and team management. Going into detail is beyond the scope of this blog post. In our Web Development Masterclass we spend the first week on this topic, so if you want to learn how to proactively manage technical debt and get tips and tricks from over 15 years of building web applications and SaaS solutions with companies and teams of all sizes, check out the Web Development Masterclass .

However, I will try to give you as many starting points as possible to get you started.

Safe Environment

Create a safe environment where people can regularly talk about upcoming challenges, spontaneous changes, and sudden problems without being blamed. If you have a daily standup, use it to encourage the team to talk openly about obstacles that have emerged. The sooner everyone is on the same page about problems, potential delays or unplanned obstacles, the sooner everyone can deal with them.

Document Technical Debt

Have a system for collecting tasks and user stories related to technical debt, so the project manager is always aware of it, and so is the development team, so you never forget about it. Everyone is aware of a feature backlog and obvious front-end bugs, but technical debt is tricky because you don't see it immediately, very often only when it's too late. So documenting it is crucial.

Pay the Interest

Once you have the first two points in place, work on the technical debt. Refine the project plan so that you can pay off all technical debt before going live or the next release. For example, reserve dedicated sprints for refactorings and technical debt reduction. If you are not working with sprints, you could set aside one week every two months, for example. You could also think about reserving a day in each sprint for technical debt reduction, but in reality this often doesn't work, because if you had that much time in the sprint, you wouldn't have run into technical debt in the first place.

Reflect and Adapt

As a developer or development team, reflect on your last sprint. If you are not working with sprints, reflect on the last two weeks. What went well, what didn't go well and how to improve things for the next sprint. In particular, think about what you estimated you could get done in the last two weeks and what you actually got done. Is there a gap between the two? If so, try to estimate the next sprint or the next two weeks with that mis-estimation in mind. You can make ambitious plans, but you must always reflect on the results at regular intervals to keep the roadmap realistic.

Habits and Processes

Find, define and optimise processes. I am not talking about processes for the sake of having processes. I am talking about guidelines and habits. As a developer, think about repetitive, tedious tasks in particular. Think of a solution to the repetitive tedious process that makes it less tedious.

I often hear that processes kill creativity. I disagree, processes that help perform repetitive and tedious tasks without a lot of thinking free up mental capacity for the creative and hard problems that challenge developers and are the fun part of software development.

Some examples of things you might want to tweak to make them less mentally taxing are clear rules for daily standups (time box, what should be discussed), clear rules for code reviews (who is responsible for getting code reviewed, define review times and make it a daily habit - for example after morning coffee or daily standup and after lunch break), clear rules for code style, definition of ready, definition of done.

Automate Quality Checks

Once you have identified processes, you may be able to implement some of them without human interaction. I'm talking about automating processes that are very static and well-defined and don't need any room for creative change. For example, introducing code formatters so that you always have a consistent coding style that is easier to read and understand.

Reduce manual testing and instead invest in writing automated tests, which is a huge time saver for developers, not only because it saves a lot of manual testing, but because refactoring and development speed can be maintained even as the project grows. Why is this? Because the biggest problem with software development in large projects is that you break existing things when you add new features or change things. Without automated testing, you don't even know if you've broken something, because you'd have to manually test the whole software project every time you add or change code.

By having automated tests that are easy to run during development, you immediately know when things are breaking and you immediately understand why things are breaking. So it's much easier to change things and it's much more rewarding when you've implemented a new feature and you can be sure that you haven't broken any of the other 378 existing features. And because you have this "proof" from all the 623 subsequent tests, the quality of the whole system is defined.

Okay, I could go on and on about tools, but I think you get the point: automation to save developers time, make development fun, and keep quality and development speed high.

The benefits of managing technical debt properly

If you work towards proactive technical debt management, you will be rewarded in many ways. Whether you are a project manager or a developer, you will feel a sense of control; there are no alligators hidden beneath the surface waiting for you, you are aware of them and can deal with them to make your way across the river safely.

Having control, tools and automated processes removes a lot of the tedious work. And guidelines and habits lead to less mental overhead, which ultimately leads to more happiness for everyone involved.

Having a culture where problems and wrong estimations can be said out loud without being blamed, but with a mindset that is solution-oriented, leads to more enthusiasm towards achieving goals than denying problems.

Having technical debt is nothing to be ashamed of, it happens in every project from time to time. If you can show me a project without technical debt, it is more likely that the stakeholders are unaware of it than that there really is none. So the key is not to prevent it but to manage and reduce it. Being aware of all the alligators at all times will help you cross the river safely.

If you want to learn more about how to deal with technical debt, quality management, project and team management in SaaS and web application development projects, I am the instructor of the Web Development Masterclass where we cover many more things and details in a technology agnostic way. For developers to team and project leads - you'll learn a lot of practical tips and tricks in this 4 week live online course. More details at www.cnc.io/wdm

Happy coding!

Join the Web Development Masterclass