My Thoughts on Technical Debt

0. Overview

Recently, I read an article titled "There are times when the heart works before the head." on the blog of a developer I deeply respect. The deep insights about technical debt shared by the author were impressive, and I was truly moved.

While the dictionary definition of technical debt is clear, I have realized that each developer may have a different perspective and interpretation of it. I had vaguely thought that one day I would organize my thoughts on technical debt and write them down, and now I feel that this is the right moment to do so. (Especially since I recently launched my official developer blog!)

1. Technical Debt Caused by Legacy Systems

Let me organize my thoughts on technical debt as they come to mind.

The first concept of technical debt that comes to mind is when a system fails to keep up with the latest technology trends.

For example, if a feature that could be implemented in a month using a modern framework optimized for a specific domain takes three months with an outdated system, it is a clear case of technical debt.

Relatively newer systems are created to address the limitations of older systems, so it is only natural that they have a productivity advantage. While this example may be extreme, I believe there are many similar situations with varying degrees of difference.

2. Technical Debt Caused by Overuse of Technology

On the other hand, obsessing over the latest trends and new technologies, and using them excessively, can also lead to technical debt.

When introducing technologies that haven’t been proven in terms of utility or stability, and choosing them based solely on their seemingly convenient aspects, one could end up making the mistake of "killing a flea and burning down the house."

Additionally, if a system becomes overly dependent on too many external modules, it can create significant obstacles when it comes to version control or system updates. I also believe that what people refer to as overengineering falls into this category.

3. Technical Debt Caused by Sacrificing Quality for Short-Term Gains

Another common form of technical debt arises when the pressure to meet a service launch deadline leads to neglecting code quality. This results in poor code design that lacks readability and scalability, ultimately creating code that is difficult to understand or maintain. Such code also falls under the category of technical debt, in my opinion.

4. Technical Debt Caused by Poor Design

When using a specific module to solve a problem, I believe it’s important not to overly customize it to fit our system.

For example, if a bug is found in the module, the module's creators will eventually release a new version with the bug fixed. However, if the module has already been excessively modified, applying the improved version to the system could become a significant challenge. By focusing on the short-term benefit of customization, we may end up sacrificing the long-term benefits the module’s creators could provide.

Additionally, if the module has a critical flaw and needs to be replaced with another one, a loosely-coupled design from the start would make this process much easier. If not, we could end up in a situation where we need to rewrite all the code from scratch.

5. My Thoughts on Technical Debt

The various technical debts mentioned earlier ultimately lead to the maintainability of the code, and I believe this is what is being explained.

If a system is left unattended for too long, it becomes legacy and difficult to maintain. Conversely, applying excessive and unnecessary technologies can also degrade maintainability. Additionally, focusing solely on short-term gains without considering code design and readability can shorten the lifespan of the code.

Ultimately, any factor that decreases the maintainability of the code can be considered as technical debt.

6. My Long-Term Strategy for Technical Debt

One day, during an interview, the interviewer asked me:

Looking at your resume, it seems like you enjoy new technologies and are interested in a variety of them. Do you think this tendency could become a disadvantage? Will you ask to apply new technologies every time something new comes out, even if it costs time and money?

(To be honest, I'm not the type to chase after new technologies exclusively, but many people seem to misunderstand me in that way.)

At that time, I hadn't deeply thought about the concept of technical debt, so I awkwardly brought it up in my response. Honestly, I wasn't particularly drawn to that company, so I don’t regret my answer. However, looking back now, I believe that adopting new technologies with a small investment of time and resources whenever they emerge is far more beneficial in the long run, both for the developer and the company's system.

Code needs to be adjusted gradually over time. I read a book called Anti-Fragile, which explains that while drastic changes can collapse a system, frequent, smaller changes actually strengthen it.

Delaying the application of evolved technologies or concepts and trying to implement them later will eventually require a sudden, drastic change. This can lead to system instability and incur greater costs. This is precisely what causes the "1. Technical Debt Due to Legacy Systems" that I mentioned earlier.

(It's much easier to try something out and remove it if it doesn't fit, but adding something in a rush when it's needed later is much more challenging.)

Of course, having experienced the issues associated with "2. Technical Debt Due to Overuse of Technology", I will avoid using excessive technology for the sake of my mental health and survival.

Similarly, overreliance on external modules can cause problems in the long run. While someone might label it as "reinventing the wheel", I believe that, in many cases, it's better to create and use your own solutions. After all, you can never fully trust someone else's code.

7. Conclusion

Delivering results quickly is not an easy task, but the true value of a developer lies in writing maintainable code that supports long-term strategy and provides lasting benefits to both customers and businesses. Since many product owners fail to understand this, it becomes an even greater challenge—but ultimately, it is the right path.