5 symptoms of a project with a tech debt problem

Part 1 of a 3-part series about tech debt

We accumulate tech debt when we choose a quick and easy solution over a more comprehensive one in software development. Examples include duplicate code, tight coupling between components, and lack of testing.

We promise we will pay back the debt “later” when we have more time. In reality though, we rarely have more time, and we’re almost always swamped with the latest business requirements we need to fulfill. If we don’t regularly pay back this debt, the tech debt becomes a serious bottleneck for further development in the project.

The first step is to recognize there is a problem. In this article, let’s explore the telltale signs of when tech debt is getting too significant to ignore.

This article is the first of a three-part series:

• Part 1: 5 Symptoms of a project with a tech debt problem (this article)

• Part 2: Tools to reduce tech debt in your project (coming soon)

• Part 3: How to keep on top of tech debt in an ongoing project (coming soon)

The symptoms

Bugs are caught in production

There’s always a possibility of bugs slipping through into production, but if this is where you’re catching most of your bugs, you have a problem. The further away from development you catch bugs, the more slow and expensive it gets for you to fix them. One of the main reasons this happens is little to no testing in your pipeline.

Infrequent releases

The frequency of your releases reveal a lot about your project. If you’re releasing frequently (e.g continuous deployments on each change, daily etc), your project is likely to be in good health. If you’re collecting changes in your dev environment to release once a week or even less frequently than that - take a look at the reasons. Are you missing automated tests, is your release process manual?What is causing the lack of confidence in releasing in shorter cycles?

Feature development is slow

This is a tricky one, since “slow” is a very subjective word. But you know you have a problem if the engineers are spending a lot of time on:

• each incremental code change during development since the feedback loop is long (e.g no way to run the changes locally so the engineers have to deploy each change on a remote server)

• understanding where in the code base they need to make changes

• debugging issues caused in mostly unrelated areas because the code isn’t properly modularized

Users tell you when your system is down

If you have to wait for your users to report that your website is down or slow, it means you could be doing a better job of monitoring your systems. Ideally you’ll want to catch latency and availability problems before they become visible to your users.

On-Call is stressful

Stressful on-call support shifts indicate the presence of tech debt. They usually involve getting alerted about urgent production issues frequently, unclear steps to resolving these issues and the resolutions being slow due to slow or nonexistent hot-fix release processes.

I’ve listed my top 5, there are definitely some more. What would you add to this list?

Next week, we will take a look at how we can start reducing tech debt in a project in part 2 of this 3-part series.

❤️ My favorite things this week

• A friend suggested that I watch this TED talk by Amy Cuddy. It is about how you can increase your confidence by changing your body language. It genuinely blew my mind. If you have 20 minutes this week, watch it!

• This LinkedIn post by Adelina Chalmers about diversity hires. She took a hard topic and addressed it beautifully.

• Nicola Ballotta wrote a self-retrospective on his 25 year engineering career. It’s 25 years worth of life and career lessons that you can learn in under ten minutes!

• Irina Stanescu wrote about dealing with failed promotion attempts. Most of us tend to react impulsively to such a situation (guilty as charged 🙋‍♀️) but this article describes how you can deal with it rationally.