Technical Debt - When Code Debt Can’t Be Paid With Just Code

Know Your Debt - What is technical debt exactly?

The term “technical debt” was coined by software developer Ward Cunningham - one of the authors of Agile Manifesto.

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. (...) The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.”

In short, technical debt (also known as tech debt or code debt) describes the result of prioritizing speedy delivery over perfect code.

In some cases, tech debt is the result of a planned decision to meet software deadlines while also shipping high-quality code within sprints. In others, it is a consequence of an inevitable error during the release of a software upgrade. Let’s take a closer look at its causes.

The four quadrants of technical debt

There are four different causes of technical debt— known as the technical debt quadrants. The four technical debt quadrants, coined by Martin Fowler, include reckless, prudent, deliberate, and inadvertent.

While some code debt may be deliberate and classified as good debt, other codes may be inadvertent and classified as bad debt.

1. Prudent and deliberate
   • stemmed from the decision to ship quickly and deal with consequences later
   • commonly used when product stakes are low, and quick delivery benefits are high
2. Reckless and deliberate
   • happens when the development team prioritizes fast delivery over quality code, despite knowing how to produce it
3. Prudent and inadvertent
   • happens when there’s a desire to produce the best code, but you find a better solution after delivery
4. Reckless and inadvertent
   • occurs when the team tries to come up with the best code while being unaware of the mistakes they are making

The two basic kinds of technical debt

Steve McConnell, Chief Software Engineer at Construx Software, suggested that there are two types of technical debt - intentional and unintentional.

Teams choose intentional tech debt for the sake of fast delivery, while unintentional debt is accidental and usually happens after implementation.

Intentional tech debt

This debt is incurred for strategic reasons. While risky, it represents a known risk that all stakeholders can document, track, and remedy at the appropriate time. Intentional tech debt can be categorized into:

• Short-term debt: Short-term debt is incurred reactively, for tactical reasons such as to use existing resources. Additionally, short-term debt can be:
  • Focused short-term debt: This includes individually identifiable shortcuts.
  • Unfocused short-term debt: This includes numerous tiny shortcuts
• Long-term debt: Long-term debt is incurred proactively, for strategic reasons such as to meet a deadline.

Unintentional tech debt

This form of tech debt arises from sloppiness, unexpected complexity, or a lack of technical expertise in software engineering. This type of tech debt may be documented, but usually, it is not because it often remains unknown for a while.

Unintentional tech debt can still be remediated, but the development process will need to be adjusted accordingly, building time into the sprint system to revisit code that has already shipped.

How to pay off your technical debt

Technical debt is unavoidable in the Scrum model, you can only do your best to keep it from accumulating. However, it is better to pay it off early than to miss the project deadline. Here is the secret to paying off technical debt from our team at FABA.

1. Establish a clear Definition of Done & coding standards
   With a clear and standardized Definition of Done, the team will be on the same page and complete all that needs to be done for a project to be delivered. By defining and following coding standards, you can avoid technical debt caused by messy, confusing, or inconsistent code. No steps skipped and no corners cut, the quality delivered will stay high and consistent with every sprint.
2. Maintain the debt list as part of a Scrum product backlog
   Treat each debt as a user story, and the estimated effort and schedule to pay off each debt is estimated the same way other stories are estimated in Scrum.
3. Identify risks and dependencies early on
   Once you have identified the dependencies and risks, you need to align the project schedules and milestones with the dependent teams or stakeholders to avoid delays or conflicts. Additionally, it is important to define clear roles and responsibilities for managing the dependencies and risks and communicate them to all the involved parties. Lastly, allocate sufficient time, resources, and contingency buffers to handle the dependencies and risks.
4. Refactor code regularly 
   Refactoring can help eliminate technical debt by removing redundant, obsolete, or duplicated code, simplifying complex or convoluted logic, enhancing modularity and reusability, and fixing bugs or vulnerabilities. Refactoring code regularly can also make it easier to adapt to changing requirements, add new features, or integrate with other systems.
5. Don’t “test it later,” do it now
   Testing is not just about finding bugs but ensuring alignment with business needs. It is the practice of verifying that the code meets the expected specifications, requirements, and quality standards. Done right, testing can help avoid technical debt by detecting and preventing errors, bugs, or failures that can compromise the functionality, performance, or security of the software.

Remember, technical debt always presents, so it is not much of a problem. It only becomes a problem when you allow it to accumulate out of your control.

The Bottom Line: Left unchecked, tech debt can be costly

Technical debt is not inherently bad. In fact, when managed properly, it can give a business greater flexibility, agility, and execution speed. On the other hand, badly managed, overused, or misapplied tech debts can all become severe problems. By working to avoid unintentional tech debt — and focusing only on intentional, well-documented tech debt — you can position your development team, and your business, for success.