4 ms·

I might be doing it wrong but I constantly pay down technical debt to almost zero. The reason I do this is because when I am working on an area of system it tak

I might be doing it wrong but I constantly pay down technical debt to almost zero. The reason I do this is because when I am working on an area of system it takes alot of thinking to understand it, thus I try to get as much done as possible in that context, because re-learning the context later is very expensive in terms of time. I'm pretty certain that means new features are implemented alot more easily. Hard to quantify though. I can say I'm always thanking "yesterday me" for finishing the job and cleaning up whatever "today me" is working on. It's possible for me to do this because I do most of my programming on my own. I don't think this approach is suitable for most software engineering processes because they tend to deprioritise technical debt.

bobkazamakis 4y ago
I agree with this, but it also requires some skilled automation or very well-defined boundaries; otherwise you spend all of your time maintaining and not enough time implementing features.
abc_lisper 4y ago
That’s hardwon wisdom! I think it’s possible to do this elsewhere if you keep it simple, restrict yourself to a feature set that one understands well.
andy_ppp 4y ago
I call this “fighting the good fight”. Hardly anywhere will prioritise making your life better, I say don’t tell them and sneak in tidy ups and refactoring as part of every task. Essentially a codebase is either getting better or worse over time, I prefer to work towards improvement rather than ossification. Having said that in some places and on some days (and working with some people) I don’t always have perfect energy for the fight.
- omgwtf1000 4y ago
  This is the approach I take too. I’ll refactor code / UI cleanup in the area I’m working in. Sometimes QA complains if they review commits, but I’ve never had to revert changes because of it.
- andrewstuart 4y ago
  Trouble with this is you need to explain why you touched a bit of code unrelated to the current Jira ticket. And if you have to explain that alot then you become a problem to the team lead.
  - schneems 4y ago
    “Now if you feel that the bare minimum is enough, then okay. But some people choose to [commit] more and we encourage that, okay?” - Mike Judge, Office Space
  - dvtrn 4y ago
    If I had to justify myself every time I took the basic initiative of fixing errant, problematic or poorly performing code just because it wasn’t ordained and blessed for me specifically I am out the door SO fucking fast… Happy to have discussions and elucidate to others the change, and make whatever documentation necessary available, but if some leader somewhere things I’m a “problem” for merely having done the work…okay, let me solve that problem too: bye. That’s an environment with serious trust issues manifesting as micro-management and I’ve got a severe case of post-micromanagement-stress-syndrome.
    - therealdrag0 4y ago
      I think where the valid problem is in terms of priority. Sometimes engineers “feel” the need to refactor something that’s not related to a high priority project and end up burning days as they weren’t experienced/competent enough to really know where that string they pulled lead and got stuck fixing newly failing tests etc. and in the examples I have in mind the context isn’t the usual “product feature must deliver pressure”, it’s actually pure engineering project, where we had to rearchitect a system before our scaling hit a brick wall, so interesting engineering work by engineers for engineers and still some folks just chase squirrels. I totally love the freedom I’ve enjoyed to fix things at my discretion in my career, but not everyone is good balancing the time/place or “picking your battles” and sometimes you gotta reign it in in others or the stuff that needs to get done won’t be.
  - di456 4y ago
- BenFrantzDale 4y ago
  I agree with you in principal. But it’s not “sneaking”. You are a professional, there’s no shame in doing the job right. Imagine if bridge-builders felt like they had to “sneak in” using the proper concrete setting schedule!
  - andy_ppp 4y ago
    Good to read you know what happened at the places I’ve worked better than me.
    - tome 4y ago
      I think BenFrantzDale was trying to be positive and encouraging!
doctor_eval 4y ago
> I might be doing it wrong Sounds like you’re doing it right! > I don't think this approach is suitable for most software engineering processes I think that’s just badly managed technical teams. What I started doing a few years ago was to group issues together by module/service. When I’d push work to the todo board, I’d include other, similar work. After all, it’s much easier to fix things when you’re already in context.
BurningFrog 4y ago
I do that on my small team. Most people aren't very good at code cleanup, so I take the janitor role, since I enjoy it and have the skills. Works pretty well for us.
mythhouse 4y ago
> I might be doing it wrong but I constantly pay down technical debt to almost zero. How can you tell that tech debt is at zero.
- andrewstuart 4y ago
  Cause there isn't a bunch of "working but only really half implemented/could be better", corner cut stuff in the system.
- hayst4ck 4y ago
  How hard is something to understand? How hard is it to operate? How often does it fail? How hard is it to change? How much time is spent in toil? These questions underpin the idea of debt. While there is no standard way to measure, I think almost any developer can look at code and either be impressed by its elegance or disgusted by its depravity.
thefourthchime 4y ago
I like to think I'm similar, much of that is also to working mostly by myself. The debt I do have is related to inheriting legacy code. That said, as much as I try to maintain a certain level of quality, eventually my designs break and I need to refactor things. In times like that I'm glad I have a good level of automated testing to catch regressions.
delecti 4y ago
Sometimes the "interest rate" on the "debt" is low enough that your effort is better spent elsewhere. If your tolerance for tech debt is super low, then maybe it makes sense for you to constantly pay it down, but there are lots of times when it's a reasonable decision to just "pay interest" on it. It's worth keeping in mind the cost of the ongoing "interest rate" vs the cost to eliminate the debt.
- hayst4ck 4y ago
  I've seen this attitude play out. At some point the debt grows to a point where leadership plays hot potato and nobody wants to take responsibility for it. Rather than fighting it, they just leave, from the bottom level all the way to the VPs/CTO that made (and profited from) the wrong judgement call. If you could measure and graph technical debt, I would find the idea of "planned debt" compelling, but the reality is is that people only understand they are in debt once they see the bill, and at that point it's too late. Rational people will see the bill and say "I don't want to pay that." If the CEO or CTO do not treat debt seriously and like it is their personal problem, that attitude will quickly be organization wide. Debt is a type of corruption. Corruption by its very nature grows greater than linearly. Just like with COVID, corruption and debt permissiveness have an R0. When one person is corrupt, then another person is also incentivized to be corrupt. Every person who is ok heaping on debt/corruption is another person who won't resist it and instead breed self-interest/defensiveness, cynicism, and learned helplessness. This all leads to a core understanding of corruption (and imho, technical debt), which is that you cannot plan for corruption and it will grow much faster than you expect. Once the culture is set, it is an incredibly hard thing to change. The people most able to make the change will have been the first ones upset by the culture in the first place, maybe enough to leave. The people who have thrived and seen organizational success and therefore gained organizational clout will be the least interested in a cultural change and the least interested in seeing the difficulty of their job go up.
mkoubaa 4y ago
If you plan to work somewhere for more than 5 years, this can be done for entirely selfish reasons. When a dev invests time improving the codebase, refactors mercilessly, and cleans up the code - they gain mastery over it, respect from their peers, and trust over the architecture. This is fantastic for your career long-term. In reality, with developers hopping between jobs, it's a difficult case to make. Ironically, a hot job market for developers ends up hurting a key mechanism for technical mastery.
Existenceblinks 4y ago
I think some of us are already doing pay as you go approach. It's roughly equivalent to this 10% but spread out in every few commits.
di456 4y ago
I tend to do this too but in a team environment, and I've gotten mixed feedback with some people pushing back on the number of changes or extra scope, and others being excited for tech debt being paid off and the value add. If the volume of changes really gets out of hand I'll split it into two smaller PR's, then deploy one PR, merge main into to the other, and deploy the other. It's a balancing act sometimes to know where to stop and call it "good enough."
fhd2 4y ago
Having run a couple of development teams on tight schedules, this is also what I arrived at, and I found it to work great for bigger teams in larger organisations too. With some caveats: 1) Be upfront about it, the PM or whoever is making the business decisions should at least be aware that the ticket is not being addressed in the quickest way possible. Sometimes that's a real problem and that conversation is worth having. Mostly it's not an issue, at least in my experience. 2) Pretty much never done while fixing a bug that occurred in production. 3) Done in separate commits / PRs. Preparatory work for the actual change, basically. This makes understanding the changes, as well as later regression testing _so_ much easier. I may also be doing it wrong, but this is what seems to have worked best for me and my teams.

bobkazamakis 4y ago

I agree with this, but it also requires some skilled automation or very well-defined boundaries; otherwise you spend all of your time maintaining and not enough time implementing features.

abc_lisper 4y ago

That’s hardwon wisdom! I think it’s possible to do this elsewhere if you keep it simple, restrict yourself to a feature set that one understands well.

andy_ppp 4y ago

I call this “fighting the good fight”. Hardly anywhere will prioritise making your life better, I say don’t tell them and sneak in tidy ups and refactoring as part of every task. Essentially a codebase is either getting better or worse over time, I prefer to work towards improvement rather than ossification. Having said that in some places and on some days (and working with some people) I don’t always have perfect energy for the fight.

omgwtf1000 4y ago
This is the approach I take too. I’ll refactor code / UI cleanup in the area I’m working in. Sometimes QA complains if they review commits, but I’ve never had to revert changes because of it.
andrewstuart 4y ago
Trouble with this is you need to explain why you touched a bit of code unrelated to the current Jira ticket. And if you have to explain that alot then you become a problem to the team lead.
- schneems 4y ago
  “Now if you feel that the bare minimum is enough, then okay. But some people choose to [commit] more and we encourage that, okay?” - Mike Judge, Office Space
- dvtrn 4y ago
  If I had to justify myself every time I took the basic initiative of fixing errant, problematic or poorly performing code just because it wasn’t ordained and blessed for me specifically I am out the door SO fucking fast… Happy to have discussions and elucidate to others the change, and make whatever documentation necessary available, but if some leader somewhere things I’m a “problem” for merely having done the work…okay, let me solve that problem too: bye. That’s an environment with serious trust issues manifesting as micro-management and I’ve got a severe case of post-micromanagement-stress-syndrome.
  - therealdrag0 4y ago
    I think where the valid problem is in terms of priority. Sometimes engineers “feel” the need to refactor something that’s not related to a high priority project and end up burning days as they weren’t experienced/competent enough to really know where that string they pulled lead and got stuck fixing newly failing tests etc. and in the examples I have in mind the context isn’t the usual “product feature must deliver pressure”, it’s actually pure engineering project, where we had to rearchitect a system before our scaling hit a brick wall, so interesting engineering work by engineers for engineers and still some folks just chase squirrels. I totally love the freedom I’ve enjoyed to fix things at my discretion in my career, but not everyone is good balancing the time/place or “picking your battles” and sometimes you gotta reign it in in others or the stuff that needs to get done won’t be.
- di456 4y ago
BenFrantzDale 4y ago
I agree with you in principal. But it’s not “sneaking”. You are a professional, there’s no shame in doing the job right. Imagine if bridge-builders felt like they had to “sneak in” using the proper concrete setting schedule!
- andy_ppp 4y ago
  Good to read you know what happened at the places I’ve worked better than me.
  - tome 4y ago
    I think BenFrantzDale was trying to be positive and encouraging!

doctor_eval 4y ago

> I might be doing it wrong Sounds like you’re doing it right! > I don't think this approach is suitable for most software engineering processes I think that’s just badly managed technical teams. What I started doing a few years ago was to group issues together by module/service. When I’d push work to the todo board, I’d include other, similar work. After all, it’s much easier to fix things when you’re already in context.

BurningFrog 4y ago

I do that on my small team. Most people aren't very good at code cleanup, so I take the janitor role, since I enjoy it and have the skills. Works pretty well for us.

mythhouse 4y ago

> I might be doing it wrong but I constantly pay down technical debt to almost zero. How can you tell that tech debt is at zero.

andrewstuart 4y ago
Cause there isn't a bunch of "working but only really half implemented/could be better", corner cut stuff in the system.
hayst4ck 4y ago
How hard is something to understand? How hard is it to operate? How often does it fail? How hard is it to change? How much time is spent in toil? These questions underpin the idea of debt. While there is no standard way to measure, I think almost any developer can look at code and either be impressed by its elegance or disgusted by its depravity.

thefourthchime 4y ago

I like to think I'm similar, much of that is also to working mostly by myself. The debt I do have is related to inheriting legacy code. That said, as much as I try to maintain a certain level of quality, eventually my designs break and I need to refactor things. In times like that I'm glad I have a good level of automated testing to catch regressions.

delecti 4y ago

Sometimes the "interest rate" on the "debt" is low enough that your effort is better spent elsewhere. If your tolerance for tech debt is super low, then maybe it makes sense for you to constantly pay it down, but there are lots of times when it's a reasonable decision to just "pay interest" on it. It's worth keeping in mind the cost of the ongoing "interest rate" vs the cost to eliminate the debt.

hayst4ck 4y ago
I've seen this attitude play out. At some point the debt grows to a point where leadership plays hot potato and nobody wants to take responsibility for it. Rather than fighting it, they just leave, from the bottom level all the way to the VPs/CTO that made (and profited from) the wrong judgement call. If you could measure and graph technical debt, I would find the idea of "planned debt" compelling, but the reality is is that people only understand they are in debt once they see the bill, and at that point it's too late. Rational people will see the bill and say "I don't want to pay that." If the CEO or CTO do not treat debt seriously and like it is their personal problem, that attitude will quickly be organization wide. Debt is a type of corruption. Corruption by its very nature grows greater than linearly. Just like with COVID, corruption and debt permissiveness have an R0. When one person is corrupt, then another person is also incentivized to be corrupt. Every person who is ok heaping on debt/corruption is another person who won't resist it and instead breed self-interest/defensiveness, cynicism, and learned helplessness. This all leads to a core understanding of corruption (and imho, technical debt), which is that you cannot plan for corruption and it will grow much faster than you expect. Once the culture is set, it is an incredibly hard thing to change. The people most able to make the change will have been the first ones upset by the culture in the first place, maybe enough to leave. The people who have thrived and seen organizational success and therefore gained organizational clout will be the least interested in a cultural change and the least interested in seeing the difficulty of their job go up.

mkoubaa 4y ago

If you plan to work somewhere for more than 5 years, this can be done for entirely selfish reasons. When a dev invests time improving the codebase, refactors mercilessly, and cleans up the code - they gain mastery over it, respect from their peers, and trust over the architecture. This is fantastic for your career long-term. In reality, with developers hopping between jobs, it's a difficult case to make. Ironically, a hot job market for developers ends up hurting a key mechanism for technical mastery.

Existenceblinks 4y ago

I think some of us are already doing pay as you go approach. It's roughly equivalent to this 10% but spread out in every few commits.

di456 4y ago

I tend to do this too but in a team environment, and I've gotten mixed feedback with some people pushing back on the number of changes or extra scope, and others being excited for tech debt being paid off and the value add. If the volume of changes really gets out of hand I'll split it into two smaller PR's, then deploy one PR, merge main into to the other, and deploy the other. It's a balancing act sometimes to know where to stop and call it "good enough."

fhd2 4y ago

Having run a couple of development teams on tight schedules, this is also what I arrived at, and I found it to work great for bigger teams in larger organisations too. With some caveats: 1) Be upfront about it, the PM or whoever is making the business decisions should at least be aware that the ticket is not being addressed in the quickest way possible. Sometimes that's a real problem and that conversation is worth having. Mostly it's not an issue, at least in my experience. 2) Pretty much never done while fixing a bug that occurred in production. 3) Done in separate commits / PRs. Preparatory work for the actual change, basically. This makes understanding the changes, as well as later regression testing _so_ much easier. I may also be doing it wrong, but this is what seems to have worked best for me and my teams.