scary hacker

What is it?

Technical debt is accrued in all software development. This is unavoidable, whatever your processes and methodology. It falls into three main categories:

  1. Intentional debt: This happens when developers do something fast due to pressure. They know it won’t scale, is not ideal, but it will work for now. This is a normal response to short-term deadlines and last-minute feature requests / fixes.
  2. Unintentional debt: This happens when developers make a call to do something a certain way without full information. That could be because senior leadership has not explained the problem sufficiently, because the developers lack expertise, or because of some unknown unknowns. These two are the most common causes of technical debt.
  3. Rot debt: This happens when dependencies are not upgraded regularly, cybersecurity falls behind, and old (sometimes unused) code remains in production. It could also be an old set of tests (from unit to functional), documentation (internal and external), and processes not updated (“that’s how we’ve always done it!”).

The worst thing is that those technical concerns create business concerns.

From increased development time, to flaky operations, to insecure deployments, those cost money and time at the business level. The more debt you incur, the more painful the repayment of the interest is. And you will pay, in full.

Therefore, tech debt should be called business debt.

What are the negatives?

The top is that you will have to pay money to fix business debt. The longer you wait, the more money you will have to pay to address the same problems. In particular,

  1. Increased Maintenance Costs. As business debt grows, the codebase becomes more complex, requiring more time and effort to change and fix bugs at the expense of new feature development and innovation.
  2. Reduced Agility and Flexibility. New features become both harder and more risky to implement and test. The operational side becomes more brittle, leading to downtime and rollbacks.
  3. Decreased Code Quality: Business debt leads to a higher incidence of bugs and defects, affecting the reliability and performance of the software.
  4. Difficult to Understand: Poorly written or documented code makes it harder for developers to understand the system, leading to errors and inefficiencies.
  5. Security Vulnerabilities. Outdated libraries, poorly written code, and lack of proper testing can introduce security vulnerabilities, making the system more susceptible to attacks. Non-compliance with security standards and regulations can lead to legal and financial penalties.
  6. Impact on Team Morale and Productivity. Few people want to work on complex, untested, unmaintainable, and undocumented code. Development, SQA, and operation staff start seeing the grass as being greener elsewhere and your best people leave first.

That said, some people advise not bothering with it at all: get as much in debt as you can on your route-to-market. Get early customers as soon as you can, get VC funding, and you can always fix things later. If your goal is to disrupt the market and exit early, then business debt is not relevant to you. It will be someone else’s problem. However, what happens when you are the buyer? What are the signs? Look out for the answers in another post.

How do you fix it?

Senior leadership must understand the impact of business debt on their ability to produce innovative and robust software. Without this, there is no way to address business debt. Unless there is support from the top (C-suite/Board), then whatever you do will be ineffective and lack substantial impact. It is a sad truth. Therefore,

  1. The most important step is to educate senior executives and leadership about business debt. It could be this article, or ideally provide metrics about the current state of debt and its impact.
  2. Listen to your team. They are the experts, they know where the issues are. If they say something needs addressing, give them the resources to address it. Trust them to prioritise what requires doing first.
  3. Slow down. If your sprint (or iteration) is packed with new features, then there will be no time to do it right or address existing problems.
  4. Shift left. More quality assurance, operation, and cybersecurity closer to the development process. Yes, it slows things down. Yes, it makes things more robust. DORA state of DevOps 2024 has all the data to back this up.

Is it really that easy?

Definitely not, but the above does help.

This is what Firmamentum does, and we can help make these things work for you. Get in touch to start reducing your business debt now.