Most of us understand technical debt as the consequence of writing “bad” code and hacking things into place. Therefore, it would be fair to assume that if we always write clean code, we would have no technical debt. That is hardly the reality.
Technical debt is the consequence of writing code about something that we don’t really understand yet. Poor code is only a fraction of technical debt.
https://www.youtube.com/watch?v=pqeJFYwnkjE
This lack of understanding is facilitated by a lack of agreement between the business needs and how software should be built, either because of.
Whenever we make a tradeoff to rush something out without fully understanding it, we are knowingly accruing technical debt, and it comes not only in the form of code, but also in terms of lack of documentation, lack of training, lack of research, etc.
The ultimate consequence of ever increasing technical debt is that changes take an ever increasing amount of time to be delivered until a point that the team and the company become ineffective and incapable of meeting the customer needs.
Bad and nasty code full of anti patterns and bad practices.
There is no excuse to ever write poor quality code. That is not related to our understanding of the problem. We should always write good code even if it is based on false assumptions about what we are trying to solve.
I like to classify technical debt based on two categories: awareness and size.
When we take on some technical debt, it might be a conscious decision that we made or an unexpected consequence of our lack of understanding. In this category, we should always strive towards making deliberate, prudent choices.
Not all tech debt is created equal. The complexity of addressing different technical debt varies in size.
Spending weeks of work in designing a solution until it is perfect is not managing technical debt. After a certain point, spending more time in designing (over-designing) a solution produces diminishing returns because: