Technical debt (Cunningham) is the debt a company “owes” to a software product. Typical components are complexity, duplications, rule violations, test coverage and documentation. This debt is also known as “software rot” (Hunt) or as “design maintenance debt (Weinberg).” Like any other form of debt, it involves paying interest at some moment, which I consider (usually) a waste. I don’t like waste, so therefore I don’t prefer technical debt.
Let me explain why I am not amused finding technical debt in one of my systems.
IF the quality of the code decreases;
THEN the velocity over time decreases;
Meaning…..we are not adding value to the software at the speed I would like to. My pseudo code will also have statements like;
- It’s harder to analyze the code = TRUE;
- It’s harder to change the code = TRUE;
- It’s harder to test the code = TRUE;
- The cost of adding new features will increase = TRUE;
- Everything will take longer = TRUE;
- More bugs found in production = TRUE;
- More technical debt added to the product backlog = TRUE;
These are all nice ingredients for an increase in REWORK for the programmers. Rework is hard to plan, leads to multitasking, which leads to a lower productivity and that leads to less profit.
So how will this impact the product backlog? The backlog represents value to the client. Value, the client is happily to pay for, but not to any price. The client will not pay €2000 for a feature which is worth €1000. The consequence is….that feature will not be build. The IT supplier could have made €1000, but now makes €0. And isn’t making money the goal of your company? (I do hope so)
I have seen systems come to a hold due to technical debt. It’s not funny. I don’t like it, I will not tolerate it. Neither should you.
Trouble and projects, closely related words. The way people act can be a great indicator to find out if your project is heading for trouble. Over the years I found some very useful phrases that could indicate bad news is coming;
- Thinking? That’s a luxury we can’t afford anymore!
- I’m doing the best I can!
- We are doing the best we can! (that’s even worse)
- That’s not my job!
- That’s (pointing) John’s job! He’s responsible for <whatever>
- Mysterious silence……
- It’s just a minor slip in the schedule….nothing to worry about….we will catch up..(yeah sure)
- A colleague wishing you good luck….
- Someone suggesting we could/should skip reviewing to catch up with the schedule….
- An increase use of lullaby words during meetings
Hi, I’m Ronald, and I’m not a developer. Today’s blog is a reaction to an email I received.
“According the csv-export for certain users: Yes, I know about the issue but unfortunately it works on my machine, so I will be unable to evaluate it (I attached the mail dialog about it).”
Excuse me? It works on my machine? Oh common, who cares “it works on your machine”? Make it work on my machine! Do you really think I’m making this up?
I know software development is difficult. I respect programmers for their creativity, testers for their pursuit to inform me about the quality of the product, users for their desperate need for that awesome feature (but we need it yesterday and can’t specify it as we should). I am sure there was a time that answer was a perfectly good reason to ignore this bug report.
BUT, I just hate the answer: It works on my machine. Let me explain why. My experience is that this answer is followed up by following behaviour; “since I can’t reproduce your problem, I will not investigate the issue anymore, and therefore I will pretend there is no problem.”
Please, next time, if “It works on my machine” happens….at least reply with a decent answer. Something like: “I understand the consequences of the issue (or not, if so help me), and know it’s important to you (dear project manager, client, sponsor, user etc). At this moment I am having difficulties understanding “why” it happens. Could I get some more time to investigate the issue, could you assist me with additional information?
I will appreciate an answer like this. Thank you.