About the tech debt

· Nacho's endeavours

What is the tech debt? #

When I first I heard about tech debt I couldn't really make sense of it. The reputations for debt and technology are really far apart so that they could be brought together in one sentence without being contradictory. And, can technology bring us anything else than good to our lives?. Well, too much or too few of it or simply applying the wrong technology to the problem can bring bad things too. Watch the bias!.

Technology debt is about now, the progress that you think you want to do, the decisions that need to be taken to make that progress happen, the predicted impact of it all in the future work and how much will all of it cost.

Rob Martin's photo in Unsplash

Lots of things together but the nut of it is kind of simple. Tech debt shows how much ready you were to make the step that you did. If you understand the problem and the complexity around very well, you'll likely be efficient with what you implement and generate as lifecycle effort in the future. If you're not.... you'll build inefficient components that will generate extra effort. This effort will generate extra costs that you'll have to deal with. Either re-implement, delete or cope with more maintainance effort than the application would suggest. Debt at the end of the day because this is money costs.

The tech debt has its part of sourcery when predicting, of course, and can only measured exactly backwards, once the damage has been done and you can understand what you did wrong. Not much scientific, huh?. This is probably why it can only be smelled after some experience in the field, I guess. What would that smell then be?.

Detecting a pattern of increasing tech debt: #

How could one be aware of not being really smart on the decisions when one counts only with the today's know-how?. With a pattern that can portray the health of the development of a component. Those should be metrics that can be applied to the component with current and past information and show a trend to the future.

A healthy development of a component is: Modifications to the component can be done often and from anyone because the complexity is approachable and can be put into production fast because the quality and testing are mature and the dependencies are addressed. Can we measure when the development drifts from this?. Let's see if we can visualize such a pattern with the DORA metrics: