An introduction to technical debt

For websites and applications, technical debt is a concept which helps us understand that during any development process sometimes the quickest and easiest solution is used in order to meet a deadline or business objective instead of the best overall solution. The 'debt' is the impact in terms of future cost in both financial and time required to work around those quick and easy solutions.

It's a bit like having a very neat and well organized storage room, everything is labeled, in boxes, on shelves. One day you are in rush and have something to put into storage, but you have not created the space on the shelf or the label for the box so you place the box on the floor to deal with later. Until this is labeled and placed on the shelf you will be moving around the box, stepping over it. This is technical debt.

You may decide that as you already have one box on the floor without a label, you can add more and then tidy up some day. This is technical debt.

Eventually the room becomes so cluttered it's impossible to use as a store room, the time required to find anything is not worth the effort. It's easier to repurpose the room next door as a store room. This is technical debt.

Why you should care about technical debt

Technical debt like any other debt needs to be managed. The consequences of ignoring technical debt will lead to some of the following outcomes:

• Increased costs for delivering new features
• Increased time for delivering features
• Difficulty in estimating level of effort to implement future changes
• Risks to the stability of the website or application
• Only developers familiar with the debt can update code
• On boarding new developers takes significant time and effort to learn how things it has been built

Ignoring technical debt will in the long run slow down the development process and eventually lead to an unmanagable and unmaintainable software code base.

What is technical debt

When developing software, if developers are under time constraints or don't have enough information to write a piece of code, they have to move quickly or improvise. It’s a bit like throwing our box onto the floor in the storage room.

This introduces complexity to the software code and the code becomes untidy and piecemeal. Code which does similar things is not merged into one clean piece of code. Old ways of implementing functionality are not upgraded to the new methods. The term used for this is cruft, and adding more cruft without fixing, leads to the code being unmanageable. The storage room has many boxes on the floor now and floor space is at a premium.

Each time a developer then starts to work on the code they have to understand all the cruft and be able to work around and manage it. In our storage room analogy they are now knee deep rummaging through boxes trying to understand where everything is.

This has a cost time and financial cost associated with it.

While we're talking about what technical debt, it's also worth mentioning what technical tech isn't. It is not a piece functionality that didn't get implemented due to time or financial constraints. It's also not bug in the software due to an error in the code.

How is technical debt accumulated

Technical debt can be accumulated in a number of ways It can be created by either the business or development side.

From the business side debt can be introduced in some of the following ways:

• Time constraints placed on development
  • "Your estimate of 6 weeks is too long. We need to ship in 3 weeks"
  • "It's too late in the development process to update to the new version of the software, we'll do it later"
• Financial constraints placed on development
  • "We don't have budget for a design phase, just go straight into development"
• Business decisions which lack sufficient technical knowledge or input
  • "We saw this new technology at the conference and want it integrated straight away"
• Ignoring standards and guidelines
  • "We can cut time and cost by not following our brand guidelines fully"

Your development team can introduce technical debt, some examples are:

• The software development team lacks coding standards and guides
• Poor quality developers
• Junior developers who lack experience and skills
• No planning around development

Technical debt can be added in a number of ways:

• Deliberately adding debt as some functionality may require corners to be cut to deliver quickly or to bring it in on budget.
• Lots of changes and updates over time to a part of the software can ultimately lead to high levels of complexity.
• Unintended debt can be added by incompatible or out of date design of the system to the business needs

How you should manage technical debt

Technical debt has to be managed. It requires understanding from both the business and development side of any software project.

The best way to pay down any debt is incrementally and over time. When adding to the debt to be aware that it's being added to and will have to paid off in future.

From a business side, allocating time and budget to development to prevent adding new debt and allowing some to debt to be paid off.

Your development team should have an understanding of the technical debt in the software and have a plan for managing it and paying it off.

Conclusion

Technical debt is a concept that should be understood across all key decision makers and manages of a software project. Without any process for managing technical debt it will always be incurred. And like any debt it can eventually overwhelm. With proper understanding and management it can be controlled and allow the software to be developed in an time and cost efficient manner indefinitely.