Technical debt, commonly referred to as tech debt or code debt, often gets a bad name as it can cause issues in your development cycle. We accrue tech debt in projects when we favour speed over quality. But actually, tech debt usually only causes problems when we don’t pay it off.

The main issue with tech debt is that it mostly comes down to prioritisation. By prioritising speed, we are able to try and test prototypes or features with our customer base before we sink or commit a lot of time and money into it. It allows us to ship a feature and iterate on it as we prove its worth. If we could always prioritise quality and perfection for every case, no one would ever achieve anything. Sometimes it’s the “it doesn’t have to be perfect, just get it done” attitude is needed for something to ultimately succeed.

However, if we were to accumulate tech debt and rarely or never address it, it will begin to slow down your process, cause blockers when wanting to develop new features, encourage building ‘work-arounds’ instead of just addressing the actual issue in the technical debt.

Here are a few examples of when accruing tech debt is, actually, a good thing:

If you are creating a proof of concept or a prototype of a product to prove that your idea has traction, demand, or that it could work, then you will want to build something for low cost, quickly and that will ultimately be a work in progress.

Here, you are prioritising speed over quality deliberately. It doesn’t need to be a perfect product because you still don’t know what that perfect product is. You are trying to work out what your customers want and how to package that up. You would likely accumulate tech debt in your infrastructure or from little to no testing.

As a contrast, tech debt you would want to avoid accruing here would be using unproven technologies, using incorrect packages, poor deployment processes, or a tightly coupled codebase.

If you are shipping a new feature to your customers - it could be in a beta phase - whilst you want it to look good and have some of the final functionality you foresee it having, you aren’t going to waste months of your teams time before you know it is what you customers want and need. Releasing a minimum viable product (MVP) or beta feature, you allow yourself to collect feedback directly from customers and view data on how they actually use it before committing to it.

EXAMPLE: This year, Slack removed their call feature from their product after having introduced huddles. They found that their new huddle feature was being used more and made more sense to incorporate some additional features into a huddle to allow their customers to use it more. If they had released huddles as a fully fledged feature with video, screen sharing, etc at the beginning (which was already being used within calls), customers may have continued to use what they knew and ignored the new feature (that they’d just sunk time and money into) completely.

Let’s say that you did start with perfect code or product, within 6 - 12 months your code will naturally accrue tech debt. Packages become outdated, updates are released or security holes are found which all need addressing as your product ages. This is inevitable and is something that every development team and product-led company will be dealing with on an ongoing basis. How you then approach this is where the maintenance of your product and code base comes into play.

If you have accumulated tech debt, here is our advice on how to best tackle it:

Are you currently lacking the resource to address technical debt? You can outsource this to an external team to work away at it whilst your team continue with core feature work. Get in touch with the team and find out how we can help you stay on track: www.contic.co.uk