4 ms·

I believe the technical debt could be measured as: The time it takes to change code that is already written. For instance, if you want feature N+1, but to do

I believe the technical debt could be measured as: The time it takes to change code that is already written. For instance, if you want feature N+1, but to do feature N+1 you need to change feature N, then the amount of time you spend changing feature N is the technical debt. So when you are estimating, you could say: We need to refrob the whozzit to make it compatible with foo 2.0, then that work could be captured as technical debt.

daemin 10y ago
That will mean Technical Debt is dependent on what features you want to implement as to how much code has to change to support it. Still makes it rather subjective and hand-wavy.
- douche 10y ago
  If the technical debt is in areas that you will very rarely go back into, then it could perhaps be considered low-interest, compared to technical debt in high-churn code paths.
- new_hackers 10y ago
  right, so the crux of the issue is that to understand how much technical debt you have, you must understand what the market wants, and what features you need to meet the demand. So I think it is extremely subjective. You could say "our product it perfect, it should never change". Thereby in itself you have accepted that all processes and information that create the product are also perfect, and therefore your technical debt is zero. You must pay nothing to achieve exactly where you want to be. You could think of technical debt as the energy lost due to friction. It is the energy lost changing from one point to another in your domain space. Perhaps "technical friction" would be a better concept for software. However, that is even more hand-wavvy and harder to measure ;-)
user5994461 10y ago
I do believe that this N+1 - N captures the idea well. One issue though: If the requirements have changed, that is not a good metrics. i.e. We did that theme blue for Iphone, now people wants it to be green AND on windows. It's not necessarily technical debt, it's cancelling everything we've done to make something else entirely (even though it may seem superficially similar). If the requirements and/or features for N+1 ignore or counter the requirements/features from N, it's not necessary technical debt, it might be you've just got no idea what you're coding and you're running in circle.
- new_hackers 10y ago
  Agreed. One could argue that at time t+1, the product that meets the market need is the N+1 version. Therefore, even if feature N developed at time t was perfect for that time, it is still technical debt at time t+1. I could think of a lot of technical innovations that at their time were the perfect fit for the market, but at a future time become technical debt. I think the point to take away is that software is just a tool, an artifact, and at the end of the day it just matters that it does what it is "supposed to do". However, civilization is dynamic, so we are constantly seeking to optimize an ever-changing potential function. So perhaps it is not the programmer that is running in circles, perhaps it is the market. So for the manager accounting for the technical debt, they must accept the change as a cost of doing business.

daemin 10y ago

That will mean Technical Debt is dependent on what features you want to implement as to how much code has to change to support it. Still makes it rather subjective and hand-wavy.

douche 10y ago
If the technical debt is in areas that you will very rarely go back into, then it could perhaps be considered low-interest, compared to technical debt in high-churn code paths.
new_hackers 10y ago
right, so the crux of the issue is that to understand how much technical debt you have, you must understand what the market wants, and what features you need to meet the demand. So I think it is extremely subjective. You could say "our product it perfect, it should never change". Thereby in itself you have accepted that all processes and information that create the product are also perfect, and therefore your technical debt is zero. You must pay nothing to achieve exactly where you want to be. You could think of technical debt as the energy lost due to friction. It is the energy lost changing from one point to another in your domain space. Perhaps "technical friction" would be a better concept for software. However, that is even more hand-wavvy and harder to measure ;-)

user5994461 10y ago

I do believe that this N+1 - N captures the idea well. One issue though: If the requirements have changed, that is not a good metrics. i.e. We did that theme blue for Iphone, now people wants it to be green AND on windows. It's not necessarily technical debt, it's cancelling everything we've done to make something else entirely (even though it may seem superficially similar). If the requirements and/or features for N+1 ignore or counter the requirements/features from N, it's not necessary technical debt, it might be you've just got no idea what you're coding and you're running in circle.

new_hackers 10y ago
Agreed. One could argue that at time t+1, the product that meets the market need is the N+1 version. Therefore, even if feature N developed at time t was perfect for that time, it is still technical debt at time t+1. I could think of a lot of technical innovations that at their time were the perfect fit for the market, but at a future time become technical debt. I think the point to take away is that software is just a tool, an artifact, and at the end of the day it just matters that it does what it is "supposed to do". However, civilization is dynamic, so we are constantly seeking to optimize an ever-changing potential function. So perhaps it is not the programmer that is running in circles, perhaps it is the market. So for the manager accounting for the technical debt, they must accept the change as a cost of doing business.