If you ask any developer what is technical debt they will probably tell you something along the lines of: Cutting corners just to make things work.
But there's another kind of debt that often goes unnoticed: just-in-case abstractions and features. These appear as a result of rationalizations such as "I might need this later" without a clear definition of what later means, or "the client will need this in 6 months when they will have to scale" without knowing whether the client intends to do that.
I recently saw this tweet from Dr. Milan Milanović and found the image inspiring: It got me thinking about technical debt. It got me thinking about all the projects using microservices, causing operational hell, when they could be way simpler to maintain as a majestic monolith. I remembered all the times I added a queueing system just because in the future, we might want to decouple Feature X from Feature Y and have them run as separate services. Most of the times that never happened.
Then I realized that what I did was introduce technical debt.
You see, when you write code that the client does not need right now or in the foreseeable future (I'm talking reaaaaaallly near future), according to Lean, you are creating waste.
First, it's waste because it's not used. Second, it's waste because you take your mental resources from current problems and invest them into could-be, would-be work. More often than not, things take longer than you expect, so you cut corners in other areas to be able to ship everything.
So working on things you might use, pushes you to cut corners on things you do use, thus triggering a vicious cycle where your desire to improve the system causes you to degrade the system. This is the cause for a lot of the strife between senior developers and architects, and devs who are on the senior path but who identify too much with their work and can't accept that it has to be simple. The former are believed to be too old and antiquated in their thinking.
As a craftsperson, one should also think about the lifespan of their work, about its maintainability and repairability. It's worth nothing that you ship shiny code, beautifully designed using patterns, with all the bells and whistles and the confetti, if it ends up unused, or worse, if it confuses the people who have to maintain it.
