Technical Debt: What is it, and how does it actually affect your startup?

This is part one of a two piece post I have planned on technical debt. Tech debt accrues in various ways, you build products fast and make short term decisions that hurt your product’s long term stability and maintainability. Sometimes a conscious decision to take on debt is made in order to hit an important deadline or reach a market position. In some cases lack of experience and adhering to best practices could leave you with a huge mess on your hands.

The term tech debt allows discussions and decisions to be made about investing in and improving your software. Your investment in tech debt is not tied to the success of the project, as it is difficult to measure the commercial success of a project based on its quality.

Why tech debt will hurt you

Productivity becomes slower and slower. Features that used to take 2 weeks to develop now take 5 weeks because your codebase becomes un-maintainable and difficult to work with.

Your feedback loop gets slower and slower and it impacts the agility your team had when it was first building the product. Build times get slower, database schemas become hard to manage, the code becomes more complex to maintain and even harder to write new features with it.

You will end up having large and slow release cycles with big bang deployments which cause huge levels of stress. As the changes are so large those releases tend to be off schedule and cumbersome.

Each new feature and code change introduces new bugs because your system has grown to be unmaintainable and it is even harder to test.

Management teams need predictability and stability. With technical debt you will be pushed to have either. Team velocity is continually lower or slow and always hard to predict due to continuous issues with the system and interruption to development time.

People get frustrated with your product and so will your team. Good people don’t like working in unhealthy software systems. They don’t like working in spaghetti code on outdated tech stacks. Engineers will burn out and get sick of fighting against a bankrupt tech stack.

Debt Smells

A code smell is a stench in your code or system that is normally flagged by people complaining about what they are working on. A debt smell could be considered a red flag on your product which you should be aware of and could indicate you are suffering from tech debt.

Below are common symptoms and indicators that tech debt exists in your platform.

• To-dos and fixme’s in the code
• Can only be changed by X (Knowledge island)
• Copy paste, similar code everywhere.
• Spaghetti code.
• “I don’t want to touch it and I don’t know what will break” — bad design that inhibits change.
• Changes which would be fast on a green field project take much longer on yours
• Old libraries and use of deprecated API’s
• Slow tests — or even worse, no tests
• Slow build system — or even worse, no build system

Tools like sonar and structure 101 exist which help you analyse these issues and track progress. They give you historical data and coverage of tests; you can even make the build fail if quality degrades which stops these types of issues arising in the future. You can’t understand the quality of your system without continual feedback with the people working day to day on the systems.

4 Quadrants of tech debt

The four quadrants identify how you can arrive in a situation of having large technical debt and the mindset engineering teams have when this happens. This quadrant is normally driven from experience (perhaps lack of) or pressures from the business.

Reckless — Can come from management decisions (like hiring outsourcing companies to build your product) or engineering decisions like putting every line of code in one file.

Prudent — normally comes from pragmatists who make decisions for the good of the business in order to hit its goals or from engineers who can see that taking the debt up front is more important than a perfect system.

Deliberate vs Inadvertent — is the conscious decision to take on technical debt vs just not having the experience to foresee it coming

To pay the debt or not

Recent studies in this area boil it down to three areas to tackle this debt.

Debt repayment — is when you decide to refactor or replace it. Only if the code is really bad you need to make it much more usable and extendable. Not something to be taken lightly, Joel Spolsky’s piece on the Netscape 6.0 rewrite says this is the “single worst strategic mistake that any software company can make”.

Debt conversion — when you have critical areas of your system that replacement is not an option you take on fixing pain points to make it more usable and adaptable for the future. Happens when you can’t afford the ideal solution, it’s not worth the cost or time is a constraint.

Accept it — When you know things aren’t great but we can deal with it. The cost of changing everything is more expensive than working with an ok codebase. The value of investing in its debt brings little value.

I hope you enjoyed my post. In the next one, I will talk about how to go about tackling technical debt. Please get in touch or comment if you would like to discuss this some more :)