Defining Technical Debt

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…

Are you Lean, are you becoming Lean or do you do Lean things?

Is Lean something you are or something you do?

From my perspective (what other point can I make???) is Lean something we are trying to be. I think (and hope) that there will never be a time when I will answer a question with “Well, we have implemented Lean Software Development and boy, we are really Lean….and Agile!”. Instead, I really would say that yes, we are today implementing the ideas and thoughts of Lean Software Development and if you ask me in ten years from now, I will most likely answer the same – unless working with something else or the need for improving the business is gone…

I think that the only way to tell how successfull we are in implementing Lean or Agile is to look on how good we are in delivering business value to our customers… quickly, repeatedly and reliably…every time!

Cheers!
/ Johan

Is technical debt waste?

How does technical debt relate to the seven wastes in Lean Software Development?

1. Extra features – I cannot see any direct correlations here
2. Partially done work – If code that is not refactored is not done, then skipping refactoring will be valid here. But I don’t think it is that obvious. Based on that argument, we can actually motivate allmost everyting by this kind of waste
3. Relearning – Does not help me that much here, or?
4. Task switching – Nope
5. Handoffs – Nope
6. Delay – Code that is not refactored will result in delay and will take longer to maintain and make changes to. So, Delay can be an effect, but is not the cause.
7. Defects – Not really, but as with delay, sloppy code will most likely result in more defects or increased cost.

In the book Lean Software Development – From concept to Cash by Tom and Mary Poppendieck, the topic complexity is one of the first topics discussed when waste is discussed. Technical debt will result in increased complexity. Adding complexity into the code is – what I can see – increasing the technical debt.

So, my current standpoint is that putting technical debt into the code base is waste. Removing technical debt is neccessary waste that should not be needed if the sloppy code was not there from the first place.

Then the next question is how we can develop code with minimal technical debt fast enough? Well, write less code, build quality into the software via Test-Driven-Development and constant refactoring might be a good start.

A few notes on Standards and Guidelines

Here is my current view on guidelines and standards (aggregated from Lean, experiences and other sources):

• Current best way of working, No such thing as “Best practice” because that only kills motivation
• I don’t want guidelines that prevent people from thinking
• Try to make them executable

When do we use guidelines?
1) When new to a domain
2) As a basis for improvment (where are we now and where is our target condition)
3) When you don’t want to make a decision and want to be “safe”

The problem with guidelines is that as soon as you are familiar to the domain of the problem, you will most likely not read any guidelines on the subject. The value from written content will be minimal, because you will not read it. The questions is also how much attention you will have on new guidlines that differs from your current way of working?

That is why I really like the idea of making guidelines executable, so when you are not following the current best way of working, you will be notified.

What kind of guidelines are not possible to make executable? How much effort is it worth creating them?