Reinertsen’s strange take on Technical debt
Having just posted my thoughts on #CompetenceDebt: The other kind of software debt and enjoying a lot of positive feedback I was excited when Donald Reinertsen posted his thoughts on Technical debt: Adding Math to the Metaphor. Like Reinertsen, I have also studied economics and sometimes despair at how little some people in software understand of it. I also agree to a certain extent with his basic premise that one should take an economic view of Technical debt.
The problem is just that Donald does not really seem to understand what technical debt actually is. From the way he describes technical debt it seems as if he is confusing it with deferred features. Technical debt is in essence a quality dimension. If you were the captain of a ship, technical debt can be likened to a hole in the hull. As captain you have two reasonable choices, you can get someone to fix the hole or you can assign people to pump water. Technical debt is when you assign people to pump water. The cost of pumping water can not be negative! The whole point with technical debt is that it incurs a cost on anything you choose to do with the system. One can argue about the size of this added cost but it is hard to argue that people will be able to create new features quicker is a system that is more confusing that before.
There is also an aspect of technical debt that is even harder to quantify. A system that is jumbled and confusing is frustrating to work with. This will over time impact the motivation of the developers to do a good job.
Niklas Björnerstedt
Note
I do not mean that technical debt must always be minimized immediately. There are valid reasons for leaving debt is some cases. Kent Beck has written about situations where he suspects that code will be short lived and he therefore chooses not to eliminate technical debt. One point I forgot to make in this post is that the cost of having a lot of technical debt can be hard predict. The story of how Knight capital lost $460m should be read by anyone planning to leave a lot of technical debt in their system.
Posted on 2013.11.14 at 15:19
Comments are off for this post.