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.