In software development, technical debt has emerged and popularized as a critical aspect that influences the quality and efficiency of software products.
You will dive into millions of articles, videos, and several particular and deep-dive books that include other new terms, more complex technical invented definitions, and psychology analysis techniques.
Today, understanding technical debt and making the right tech decisions is more complex than ever; the same reason that makes it easy to build is the same reason that makes it harder to maintain and manage: OPTIONALITY.
Technical debt is still burdensome to manage and efficiently measure even for Adam Tornhill, a leading expert in the field, but why?
My belief on this topic is slightly controversial and different. Still, since I’m always talking from my personal experience with honesty and well-intentioned words, it is my truth, and I hope you can use it to spread good debate.
Technical debt was defined in early 1990 by one of the creators of the first wiki, Ward Cunningham. He analogizes the concept to financial debt, and he describes it like:
“The accumulative cost incurred over time when we develop any type of system.”
In general, it encloses the accumulated cost of additional work needed in the future due to the compromises (or bad choices that were not so bad some time back) made in the present.
Most of the technical debt (but not all) comes from the start of any software or product, the Design phase.
If we do not avoid this phase at all, which often also occurs when designing simple or complex systems, we intentionally or unintentionally tend to believe that we understand the problem we are trying to solve when, most of the time we don’t, we define architecture designs and patterns that should help us quickly evolve our systems to a less and less complex one but, the truth is that in practice, this is harder that most architect engineers will tell you.
We live in a world of short roadmaps and tight schedules, featuring factory-products corporations unable to change as fast as technology and, more often, systems and businesses that cannot evolve faster than society.
Software developers are constantly building on top of assumptions made by others (corporations, managers, architects, product owners, scrum masters). We expect these people’s outputs to be excellent documents or diagrams with great explanatory notes that you can easily understand. Still, there are often no such good notes or clear diagrams, and not the time available to discuss this information with you when you need it.
As a tech lead and engineer, I always expect suboptimal code quality, inefficient designs, or deferred necessary work that needs to change over time. I understand that technical debt is part of the process; I embrace and accept that just a few simple lines of code, the newest and modern dependency library, or a simple system design pattern can become obsolete someday.
We work in a dynamic landscape where complexity often increases, and Conway’s laws exist, so technical debt is an inherent challenge that demands attention from all developers, organizations, and technical managers.
Still, in the real world, not all clouds are blue.
Developers are ordinary people (contrary to recruiters’ belief), persons who sometimes do not have time to read not even the latest tech news due to tight schedules; we ignore non-mandatory bug fixes, avoid refactoring as much as possible unless it is a sprint task priority, we avoid updating dependencies that have not been updated for months, we take shortcuts bypassing good practices and creating poor documentation to meet deadlines, and being honest sometimes we do not have organizational access to modern cloud infrastructures that allows building quickly and more efficiently, we often have to remain coding in outdated and inefficient technologies, refactoring the same full of bugs legacy code because is too risky to change for many business reasons that will never be explained because the only person that knew the real reason leave years of several month back.
The bigger you dig into this topic, the more you will find the definition is not the only thing you need to know; several technical debts exist; you can start here to see some general ideas, read this book summary or the entire book if you which, and please do let me know if you agree with me in the comments below.