Technical debt

What is technical debt?

Technical debt is a decision about simplifying the functionality implementation taken by the development team. This decision givesshort benefitsand introduces afuture commitment to improving the code structure`.


A software provider decided that usernames and passwords will be temporarily stored in a file instead of a database. This decision was made in spite of what the specification says about the mandatory storing of the data in a database. This simple shortcut allowed to deliver the software on time. Both the customer and the provider agreed to this temporary solution.

In another version of the story, the provider has taken some extra time to pay off the technical debt taken earlier and implemented the final solution instead of a temporary one. This time, he was following the specification rules. The data was stored in a database and the debt was paid off.

Where is technical debt coming from?

There is no single source of technical debt. Here is a list of most common sources:

  • A pressure to market on time (e.g. forcing unrealistic deadlines)
  • The development process done in a wrong way (e.g. misunderstood SCRUM)
  • A lack of domain knowledge in the development team
  • A lack of tests (unit/integration/regression)
  • A poor team cooperation
  • Skipping or postponing the refactoring
  • A lack of programming standards
  • A lack of technical knowledge or/and technical leader
  • A lack of person responsible for the code

Technical debt costs

A software provider, in order to deliver the software on time, can make a technical debt in some areas not visible for the customer. By the time the software is in a production phase, everything seems to be working fine but the future extension is actually more expensive. The debt has to be paid off eventually anyway and the previously skipped functionality needs to be implemented.

Adding new features

Adding new features is both more difficult and more expensive. If a new feature uses components affected by a technical debt, the development process will extend and the already implemented features can be affected as well. A new feature could be for example the username monitoring, as described above. Monitoring module will not work effectively if it reads data from a file.

Another thing is also the possible increase of the technical debt due to the provider taking these kinds of shortcuts.

Fixing bugs

Similar problems may occur during the defect fixing. A technical debt can be taken to fix the bug. Eventually, some of the bugs may be caused by the technical debt itself.


If we want our software to be cheap in maintenance, we need to make sure it is in as little technical debt as possible. Ignoring this aspect while buying software usually leads to problems in the future and the increase of the maintenance costs.