QUOTE REQUEST
share

The term “Technical debt” was first introduced by Ward Cunningham. Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

Very often startup companies use this concept to put their products on the market faster than competitors, show results to their clients or achieve any visible advantages. From a technical point of view, it doesn’t mean that the decision has to be non-optimal. Meaning –  you don’t provide “dirty” code or unstable architecture. On the contrary – it has to be a small thing that won’t harm the whole solution and can be changed or improved later in future releases. In other words, it’s a work you can postpone, but it has to be done eventually, otherwise, it will harm the project.

It the software solution malfunctioned after the release even though the development team used the best testing software and practices, but there was an unexpected user workflow – it is not a technical debt. But if during the development process there was an issue with some part of the code that could possibly become critical later and nobody wanted to deal with it – that is a definite technical debt.

The reasons for the technical debt:

  1. Business pressure
  2. Lack of understanding of the possible consequences
  3. Code monolithicity
  4. No testing
  5. No documentation
  6. Miscommunication
  7. Deferred refactoring

Of course, it is better to eliminate the possibilities of the technical debt on your project. For that reason, project steps should be described from “start” to “finish” with the clear indication of the intended result. What steps should be taken in order to prevent it?

  • Project Backlog. Broadly used in Agile methodologies, Scrum in particular. All the works that are left to be done on the project should be indicated in the backlog so that everyone on the team is able to see the process.
  • Quality as a rule. When the team is oriented to create quality solutions, follows the established processes and maintains constant inner communication – then there is no place for the technical debt.
  • Honesty with clients. Not every client has a technical background, so there might be a need for explaining what is technical debt and how it may occur. Talk money – provide the CBA (cost-benefit analysis) and indicate how the costs might change if the technical debt is not anticipated.

Just remember, that this is not a catastrophe if the debt occurred, it is important how you and your team choose to deal with it.

Let's discuss your project

latest posts