Introducing technical debt into the code base is waste. Yes, but what do we mean with technical debt. In this post I will try to aggregate and define what meaning those words has to me.
Hypothesis: Technical debit is when you are making short term decisions on the price of long term quality.
Why do I like the term?
I like the words Technical Debt because it illustrates the balance of making short and long term decisions. You can make short term decisions, but if you are increasing your debt, then sooner or later you will have to pay your debts. And if you have built up a large pile debts, then the rent you pay on the debts have large impact on what you do today.
isn’t Technical Debt another word for…?
Violating non-functional requirements, Writing legacy code,Making systems not maintainable, etc…?
Yes, I think so, but I don’t really care, because what I like is that there is something with just two words, that can create a thought and content placeholder for a really important concept in software development.
What is Technical Debt then?
Looking on things from the Cooperative game perspective written by Alistair Cockburn, I would say that it is when you are not focusing on your current game and not creates an advantagous position for the next game.
Further questions
When you are making short term decisions that have impact on other systems, is that also technical debt? Or, is there something that is called enterprise debt? Well, I think this might be a dangerous path to walk here.
Is the words making things too simple? Are we trying to include too much comlicated issues in just two words?
References
– I think Alistair Cockburn describes it quite well in the Cooperative Game.
Hmm, the discussion relating to this topic is not finished…
Johan Nordin's Weblog 