7 ms·

One amendment I always wanted to make was to have a "technical debt dial". You could stick it on the wall next to the scrum board. The debt dial should be from

One amendment I always wanted to make was to have a "technical debt dial". You could stick it on the wall next to the scrum board. The debt dial should be from 0% (spend all the time refactoring) to 100% (spend zero time refactoring, get it out at all costs). Management should have complete control over the dial. Developers should have control over what kind of refactoring they do (ideally the retro should have a question "what debt/tooling issues caused you the most pain this sprint? and a parallel track for debt/tooling stories").

gearhart 10y ago
When I read this I assumed you meant a dial that represents the current level of technical debt, rather than a dial that represents how much technical debt you're allowed to accrue. The other interpretation might be a neat solution. Allow developers to indicate publicly what proportion of the time their last tasks took, they should have taken had there been no technical debt. It would handle the communication from developer into business-speak pretty effectively.
- ScottBurson 10y ago
  At the very least you need both dials! If you have only the one that management sets, saying how much time to spend refactoring, it will always be at 0. (Okay, they don't literally have to be dials, but there has to be some communication of the kind you describe, so management has some idea how much time is being lost.)
  - user5994461 10y ago
    That seems utterly wrong to me. I'd expect any manager worth is salt to put that at a 10% or 20% (basically anywhere NOT 0) and uses that number as a reminder to devs that part of the job description includes MAINTAINING the system in proper condition, not just piling up new stuff on top of the existing random stuff. Same as a car needs regular maintenance, a dev project needs regular maintenance.
  - crdoconnor 10y ago
    >At the very least you need both dials! If you have only the one that management sets, saying how much time to spend refactoring, it will always be at 0. Management decisions are usually CYA based, and leaving the dial set at 0 both exposes them and gives developers a get out of jail free card. i.e. leaving it at zero is suicide. That's the whole point of making it a trackable dial. Probably what would happen in most cases is it would fluctuate between 30% during average times and 0% during crunch times.
richardwhiuk 10y ago
In my experience, you struggle to move that dial from 100%.
- crdoconnor 10y ago
  In my experience, once it becomes a tracked metric that can be used to destroy a manager's career you can bet the dial will start to move.
mirekrusin 10y ago
For most companies static 100% image would do for this dial.
- crdoconnor 10y ago
  Only if it's untracked. If it's tracked and the responsibility of management it'll go down.
daemin 10y ago
One question I have is how does one actually objectively measure technical debt? I mean by anything more than a guess or intuition. Does every singleton/global variable count? Does every comment with a HACK count? What other factors contribute to technical debt, and by how much?
- new_hackers 10y ago
  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 ;-)
Udik 10y ago
I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code. I'm not sure I ever found myself in the position of writing bad code just for the sake of speed - I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or because of bad design and planning. But to get a feature out quicker, no. If anything, it seems to me that writing bad code requires more time than writing clean and elegant code. In the end, "technical debt" becomes a way to shift the blame from your own (the team's) inadequacy at planning, designing and developing, towards supposed time constraints that always lie outside of the team's responsibility.
- JoeAltmaier 10y ago
  I see technical debt as being that code you haven't written yet. You just ignore the errors from misaligned data instead of writing the date sanitizer. You monitor and hand-reboot processes that leak instead of finding the leak/automating the reboot. and so on.
- new_hackers 10y ago
  I think the "speed" part is that once you realize it is bad code cause you didn't know how to do it better, you don't have the time to scrap it and start over.
- nilkn 10y ago
  I have to disagree with this comment. Technical debt is sometimes the result of just one lone cowboy coder, but even then there's some responsibility across the team because that means his or her code passed all reviews, i.e., nobody took ownership for the overall team's code quality and vetoed the bad code. Time constraints can certainly be relevant too. It's not always an artificial shift of blame. For instance, time constraints could be why the code passed review to begin with. And some programmers certainly do write worse code when they have to do it quickly. Typically, the code itself doesn't look all that bad in a vacuum, but it presents problems months down the line when a new feature needs to be added or an existing one changed in a non-trivial way. There was little forethought in its design. Or, let's just look at the ways you said you might write bad code: > I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or because of bad design and planning In other words, these things can cause you to write bad code: 1. You just didn't know better. 2. Unclear requirements at the start. 3. Bad design and planning. In (1), you might realize after writing some code that you didn't quite know what you were doing and you should refactor it, but you're now under pressure from management to just get it out. Oops, no time to refactor. Now code that you know is bad is going into production, and it'll bite you in six months. For (2), the reason the requirements weren't clear is because not enough time was spent by management/product owners/designers on clarifying said requirements. For (3), it's the same thing -- bad planning is often the result of time constraints (notably, time constraints which may not be visible to you as a rank and file programmer).
st3v3r 10y ago
Management is just going to leave it at 0% the whole time. Once in a great while, if you're lucky, you might get 5-10%

gearhart 10y ago

When I read this I assumed you meant a dial that represents the current level of technical debt, rather than a dial that represents how much technical debt you're allowed to accrue. The other interpretation might be a neat solution. Allow developers to indicate publicly what proportion of the time their last tasks took, they should have taken had there been no technical debt. It would handle the communication from developer into business-speak pretty effectively.

ScottBurson 10y ago
At the very least you need both dials! If you have only the one that management sets, saying how much time to spend refactoring, it will always be at 0. (Okay, they don't literally have to be dials, but there has to be some communication of the kind you describe, so management has some idea how much time is being lost.)
- user5994461 10y ago
  That seems utterly wrong to me. I'd expect any manager worth is salt to put that at a 10% or 20% (basically anywhere NOT 0) and uses that number as a reminder to devs that part of the job description includes MAINTAINING the system in proper condition, not just piling up new stuff on top of the existing random stuff. Same as a car needs regular maintenance, a dev project needs regular maintenance.
- crdoconnor 10y ago
  >At the very least you need both dials! If you have only the one that management sets, saying how much time to spend refactoring, it will always be at 0. Management decisions are usually CYA based, and leaving the dial set at 0 both exposes them and gives developers a get out of jail free card. i.e. leaving it at zero is suicide. That's the whole point of making it a trackable dial. Probably what would happen in most cases is it would fluctuate between 30% during average times and 0% during crunch times.

richardwhiuk 10y ago

In my experience, you struggle to move that dial from 100%.

crdoconnor 10y ago
In my experience, once it becomes a tracked metric that can be used to destroy a manager's career you can bet the dial will start to move.

mirekrusin 10y ago

For most companies static 100% image would do for this dial.

crdoconnor 10y ago
Only if it's untracked. If it's tracked and the responsibility of management it'll go down.

daemin 10y ago

One question I have is how does one actually objectively measure technical debt? I mean by anything more than a guess or intuition. Does every singleton/global variable count? Does every comment with a HACK count? What other factors contribute to technical debt, and by how much?

new_hackers 10y ago
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 ;-)

Udik 10y ago

I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code. I'm not sure I ever found myself in the position of writing bad code just for the sake of speed - I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or because of bad design and planning. But to get a feature out quicker, no. If anything, it seems to me that writing bad code requires more time than writing clean and elegant code. In the end, "technical debt" becomes a way to shift the blame from your own (the team's) inadequacy at planning, designing and developing, towards supposed time constraints that always lie outside of the team's responsibility.

JoeAltmaier 10y ago
I see technical debt as being that code you haven't written yet. You just ignore the errors from misaligned data instead of writing the date sanitizer. You monitor and hand-reboot processes that leak instead of finding the leak/automating the reboot. and so on.
new_hackers 10y ago
I think the "speed" part is that once you realize it is bad code cause you didn't know how to do it better, you don't have the time to scrap it and start over.
nilkn 10y ago
I have to disagree with this comment. Technical debt is sometimes the result of just one lone cowboy coder, but even then there's some responsibility across the team because that means his or her code passed all reviews, i.e., nobody took ownership for the overall team's code quality and vetoed the bad code. Time constraints can certainly be relevant too. It's not always an artificial shift of blame. For instance, time constraints could be why the code passed review to begin with. And some programmers certainly do write worse code when they have to do it quickly. Typically, the code itself doesn't look all that bad in a vacuum, but it presents problems months down the line when a new feature needs to be added or an existing one changed in a non-trivial way. There was little forethought in its design. Or, let's just look at the ways you said you might write bad code: > I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or because of bad design and planning In other words, these things can cause you to write bad code: 1. You just didn't know better. 2. Unclear requirements at the start. 3. Bad design and planning. In (1), you might realize after writing some code that you didn't quite know what you were doing and you should refactor it, but you're now under pressure from management to just get it out. Oops, no time to refactor. Now code that you know is bad is going into production, and it'll bite you in six months. For (2), the reason the requirements weren't clear is because not enough time was spent by management/product owners/designers on clarifying said requirements. For (3), it's the same thing -- bad planning is often the result of time constraints (notably, time constraints which may not be visible to you as a rank and file programmer).

st3v3r 10y ago

Management is just going to leave it at 0% the whole time. Once in a great while, if you're lucky, you might get 5-10%