Whenever you are forced to leave some parts of your code with “To Do”, “Refactor” or “Review Later” that is an additional part of technical debt that is acquired. In this way, you receive Cash (liquidity) to buy Time (time). You arrive at the delivery, launch the product on time and have a prototype to teach an investor. But you cannot forget the cuts in code quality, because that’s your technical debt. It is something that you must and must pay for.
If, otherwise, the obvious and you continue to develop from there, your product will become increasingly less stable and the maintenance cost will go through the roof. To continue with the most real analogy, it is like asking for another loan to pay off the debt you already had before, once and again. At first, the thing seems to work, but it never stops increasing to cover interest and other expenses, it’s like a snowball that keeps rolling down the hill. This is the reason why it is important to allocate adequate time to refactor and even often rebuild the indicated part of the code.
Although we are familiar with the situation, we have found a shortcut to get Time (delivery) and avoid Technical Debt at the same time. But as a result, in the end, we get a new form of debt, something I like to call Functional Debt.
Functional Debt
I have collected information for this idea and I have found very few references to this phenomenon, and honestly, it never resembles the initial idea I had of it. In this article written by Mark Barnes, it is described as the breach of the YAGNI principle. When we choose a heavy framework for what should be light and small. When the functionality offered is greater than needed, the development and maintenance of those extras becomes Functional Debt.
When I imagine Functional Debt that is not the definition that I have in mind. The way I see it, is that in order to make a delivery on time, the functionality is partially implemented. The functionality itself suffers due to the cuts. Imagine that the functionality that we have to deliver is a simple form with fields for file impute. As we get closer to the delivery time and do not want to introduce a Technical Debt, we decided to simplify the functionality. We eliminate the drag and drop of the attached documents, support of multiple files, and the verification of fields on the legitimacy of the information.
Our application works perfectly well, the code is clean (the parties present do not need improvement), and it has been delivered on time. It is a miracle! Well, not really. Doing so, we allow storing invalid information in our database and the “user experience” is not good enough. Our code is immaculate and does exactly the function we want. We do not have technical debt, but functional debt.
Later, we will have to go back to this form, add new parts, integrate a valid service and change the UI. As time passes, developers will not take care of what is missing. They will need time to study what is missing, and they will have to deal with the toxic information that we pass in our database. The time spent on it is greater than needed in the first place to have full functionality. It’s the cost we pay, the interest on our debt. Its effects are less harmful than those of Technical debt, even so you need to keep an eye and take care of them.
The developer who exposes situations like the one described above is normally seen as an enemy of productivity. Since it asks for time to work on something that already works. There are benefits in stopping for a moment and thinking about the functional debt that we may be acquiring, since it can save us more than one headache in the future.
About Software Testing
How well does your developed software or application behave is something that can make or break your business. The behavior of your application depends on how comprehensively it is tested. Compromising in testing means compromising on your customer count and your business reputation. So, testing your application should never be overlooked.
