3 ms·

YES! As a developer I can FEEL the pain of our code debt but I don't know how to convey the importance to management. There's definitely a balance to it and I'm

by wes-k 9y ago

YES! As a developer I can FEEL the pain of our code debt but I don't know how to convey the importance to management. There's definitely a balance to it and I'm certainly biased in favor of letting those in the code make the judgement call. One solution I thought of was to enact a 20% code debt policy, similar to google's 20% time but for code debt. Hey developer, is there something causing you pain? Fix it!

maxxxxx 9y ago
"One solution I thought of was to enact a 20% code debt policy, similar to google's 20% time but for code debt" That's sort of how I do it. The key is to never tell management explicitly. It's just normal part of the job.
- wes-k 9y ago
  Ya I usually "sneak in" cleanups associated with stories. The problem with that is it doesn't allow for bigger more impactful refactors. So usually the debt that hurts the most never gets dealt with.
  - maxxxxx 9y ago
    I find that a lot of pain is in the details that can be fixed with a few hours or days of work.
- humanrebar 9y ago
  This approach tends to work well. If they don't want to worry about it, they've effectively delegated it to you. The only problem is that this setup is subject to the tragedy of the commons. If it takes 25% more work to make a change cleanly, the developers throwing hacks around look 20% more productive if we ignore technical debt. And, worse, they're often the only people in the world that understand the hacks, so they get to be the hero-experts that come in and save the day when everyone else is trying to figure out what the hell is going on. So even if we'll do our best to bake the cost of cleanup into our day-to-day tasks, that only works as long as a critical mass of the developers in the organization do the same thing. Otherwise, you'll have a full time job plus some just cleaning up messes.
  - maxxxxx 9y ago
    You have to trust that doing good work makes things better and that you are actually faster over time than others who create a mess. If you don't get any benefits from clean code then it's not worth it. This works only if you own your part of the code for a some time so your investment can pay off.
rusk 9y ago
In the scenario you describe the only thing you can do is pad your estimates. Don't do this explicitly but if there is some objection to cost make the assertion that the usecase though straightforward has to contend with certain legacy issues. There are two outcomes (1) they trust you, and grudgingly accept your estimates. You address what debt you can and ensure padding doesn't increase the next time thus trust is maintained (2) they force a timeline on you, in which case when it's late or broken in production you can at least say you needed more time. There is a third more egregious possibility, that they get an alternative estimate from elsewhere or one of your colleagues and in my experience this is the principle weakness to standing your ground "we'll take our business elsewhere" and I am truly sorry for your trouble if that is the case. Hopefully you have secure employment and the whole mess then just becomes the problem of the person that undercut you. Of course, in all these situations you have to make a call based on your personal/organisational circumstances but I just want to say that ultimately being upfront, diligent and continuously demonstrating trustworthiness may not always pay off in each particular instance, but over the longer term as reputation accrues they do.

by wes-k 9y ago

maxxxxx 9y ago

"One solution I thought of was to enact a 20% code debt policy, similar to google's 20% time but for code debt" That's sort of how I do it. The key is to never tell management explicitly. It's just normal part of the job.

wes-k 9y ago
Ya I usually "sneak in" cleanups associated with stories. The problem with that is it doesn't allow for bigger more impactful refactors. So usually the debt that hurts the most never gets dealt with.
- maxxxxx 9y ago
  I find that a lot of pain is in the details that can be fixed with a few hours or days of work.
humanrebar 9y ago
This approach tends to work well. If they don't want to worry about it, they've effectively delegated it to you. The only problem is that this setup is subject to the tragedy of the commons. If it takes 25% more work to make a change cleanly, the developers throwing hacks around look 20% more productive if we ignore technical debt. And, worse, they're often the only people in the world that understand the hacks, so they get to be the hero-experts that come in and save the day when everyone else is trying to figure out what the hell is going on. So even if we'll do our best to bake the cost of cleanup into our day-to-day tasks, that only works as long as a critical mass of the developers in the organization do the same thing. Otherwise, you'll have a full time job plus some just cleaning up messes.
- maxxxxx 9y ago
  You have to trust that doing good work makes things better and that you are actually faster over time than others who create a mess. If you don't get any benefits from clean code then it's not worth it. This works only if you own your part of the code for a some time so your investment can pay off.

rusk 9y ago

In the scenario you describe the only thing you can do is pad your estimates. Don't do this explicitly but if there is some objection to cost make the assertion that the usecase though straightforward has to contend with certain legacy issues. There are two outcomes (1) they trust you, and grudgingly accept your estimates. You address what debt you can and ensure padding doesn't increase the next time thus trust is maintained (2) they force a timeline on you, in which case when it's late or broken in production you can at least say you needed more time. There is a third more egregious possibility, that they get an alternative estimate from elsewhere or one of your colleagues and in my experience this is the principle weakness to standing your ground "we'll take our business elsewhere" and I am truly sorry for your trouble if that is the case. Hopefully you have secure employment and the whole mess then just becomes the problem of the person that undercut you. Of course, in all these situations you have to make a call based on your personal/organisational circumstances but I just want to say that ultimately being upfront, diligent and continuously demonstrating trustworthiness may not always pay off in each particular instance, but over the longer term as reputation accrues they do.