Techn(olog)ical debt and how to avoid its dreadful consequences

/ 5 minutes of reading
technological debt
Michał Nowacki
Latest posts by Michał Nowacki (see all)

The best explanation we have encountered of what the technical/technological debt actually means was by comparing the concept to… doing the dishes!

If you are one of those who not particularly enjoy cleaning up after dinner right away, you will be able to relate. When you finally find the motivation to handle all that mess, it is very likely it will take a lot of time and effort. Getting rid of that dried out food waste is probably going to drive you crazy. On the other hand, if done immediately, it is not going to take more than just a couple of minutes. A drop of dish soap and a sponge is all you need!

Same with IT projects. Taking care of the issues right away is going to save resources in the future. If you are going to wait and leave unresolved bugs behind, they will definitely pile up as a stack of dirty dishes in your kitchen sink.

Technological debt – what is it, really?

Technological debt (sometimes also: technical debt, code debt or design debt) stands for an implied cost of additional rework caused by choosing an easy approach to software development.

The phenomenon has been widely known since the 90s. An example of it was initially dished up 😉 by a well-known and influential software engineer and computer consultant from the USA, Edward Yourdon. As he described it, the technical debt means the lack of the bigger idea, plan or project behind the software in progress.

The term is also associated with Howard Cunningham, a computer programmer who developed the first wiki. The pioneer in design patterns and extreme programming was not satisfied with the quality of the application he was working on. He then stated that some practices generate a technological debt, which will then result in a difficult and slow development of a given programming project. Over time, the concept evolved to take on more general meanings.

Currently, it is understood as a part of an IT system created without taking care of the quality of the code. It means that day-to-day technological debt is growing and influencing the work of developers around the world as we speak.

Common causes of the technical debt

Technical debt can be caused by multiple reasons.  To name just a few:

  • Insufficient up-front definition, where development starts before any design takes place
  • Business pressures, where the investor requires the release before all the necessary changes are complete
  • Lack of process or understanding, where managers make decisions without considering the implications or following any of the professional software development methodologies
  • Tightly-coupled components, where functions are not modular, the software is not flexible enough to adapt to changes of the business needs
  • Lack of a test suite, which encourages quick and risky band-aids to fix bugs
  • Lack of collaboration, where knowledge is not shared around the organization, or junior developers are not properly mentored
  • Parallel development on two or more branches accrues technical debt because of the work required to merge the changes into a single source base. The more changes that are done in isolation, the more debt is piled up
  • Delayed refactoring – As the requirements for a project evolve, it may become clear that parts of the code have become inefficient or difficult to edit and must be refactored in order to support future requirements. The longer that refactoring is delayed, the bigger the debt.
  • Lack of procedures, where industry standard features, frameworks, technologies are ignored
  • Lack of knowledge, when the developer simply does not know how to write elegant code
  • Poor technological leadership, where poorly thought out management, increases the technical debt of the software.

How can you avoid technical debt in your software?

In general, the technical debt is a result of poorly made decisions. In order to avoid its dreadful consequences, it is important to cooperate with specialists who know their job and are following the rules of modern agile software development. One of the fundamental principles of such methodology is examining the quality of code as you proceed with the project.

At the same time, it is equally important to provide the compatibility of the system and your individual business needs. The biggest advantage of the agile approach is allowing the change at every stage of the implementation. It means that you can take the project and start expanding it in a totally different direction whenever you see fit.

While searching for a software house, look for an organization experienced in the framework of Scrum. We recommend it because you and the team do not need to follow a strict documentation only for the sake of it. There is no requirement of signing a specification before moving on with the development. As the Product Owner, you are fully in charge of how your software is going to look like. Above and beyond, there is no technical debt! Because you receive a working piece of software in short periods (Sprints) you have the full control over the quality of your application. There is basically no risk of leaving unsolved bugs and problems behind and having to deal with them in the future.

Summary

A technological or technical debt (as you will) is a real threat that influences everyone who has to do with software development. We cannot deny that it is going to be difficult to get rid of the consequences of not paying it off globally. What you – as an entrepreneur – can do, is not to add to it! Or, at least, pay your dues as soon as possible.

If you are looking for a business partner to help you along the way of a software development project – ask them about their experience in agile methodology. This is objectively the best way to stay in control of the quality of the code. Do not be afraid of making changes in your software. If you see the anticipated version is not going to satisfy your evolving business needs, modify it! Also, be confident asking for a proper training for admins and users. A professional software house has to provide the support to make sure that… no dishes are pilling up in your sink anymore.

Michał Nowacki
Latest posts by Michał Nowacki (see all)
Scroll to Top