I may be controversial, but I would like to raise the topic of technical debt. The development team uses this term to be understandable to business. We do not always realize that business may look at it completely differently. In my opinion, this is due to a misunderstanding of this concept by both parties.
What is technical debt?
Before we begin, I would like to point out what I think technical debt is. Technical debt is a concept in software development. It indicates the cost that must be incurred to make additional changes. That is because choosing a faster (more straightforward) solution now instead of working on a better solution would take longer.
It may be complicated, but it’s a simple relationship. Now we are achieving something faster, at the cost of potentially longer time for design changes in the future.
If you want to know more details or examples, see Wikipedia.
Is it a good solution for the company?
Sometimes technical debt can turn out to be a good solution for the company. It allows you to provide functionality, start the project from the spot. You can come across the phrase that, like financial debt, having some technical debt is healthy.
It is not something I agree with. It is not always, but most often, having any kind of debt is not good. We are attached, and we have commitments that limit our possibilities.
What’s wrong with this debt?
Companies are making changes that are based on rotting foundations. Like a house with a weak foundation, it cannot last very long. There is often no time or courage to say “stop, time to fix the basics” at some point.
Companies can only be as agile as their foundations allow. Unless changes are made, there will be a point where it will be necessary to tear down the design. The entire system will have to be prepared from scratch.
Incurring technical debt has become an accepted method of trying to increase the pace of development. Most often, however, it is counterproductive and much more destructive than assumed.
A programmer trying to deliver the promised functionality at a given time often makes some choices. These are non-trivial choices. The costs of it we will feel for a long time. Often, the desire to save a few days now means that we decide to use workarounds instead of modifying the system and improving its most confusing parts. At some point, there are already so many workarounds and fragile functions that the whole thing is no longer maintainable.
I want to emphasize that debt should not be an excuse and an explanation. It is the entire team’s role, both developers and business, to make decisions together, which will be the best for the company.
Summary
Business doesn’t understand technical debt because it is associated with an agreed improvement plan. Debt is something that we incur consciously, wanting to achieve something faster.
A missed opportunity is a much better word. Poor project foundations can be a threat to the company. At some point, development can be blocked. It will be necessary to introduce changes to be able to deliver anything at all. That means a chance for opponents to eliminate us from the market.