4 ms·

There is no "perfect balance", but you need tech leads and PMs to understand that you are aiming for a balance where your tech debt is under control and you are

There is no "perfect balance", but you need tech leads and PMs to understand that you are aiming for a balance where your tech debt is under control and you are continuously and consistently delivering business value. So far, I've failed to verbalise exactly how I achieve that in my org, but it's a combination of strategies and tactics like timeboxing refactorings, setting new tech tryouts as experiments that you re-evaluate, iterative development, and recognizing that you are never getting perfect code, nor a perfect balance.

ecfi 3y ago
> So far, I've failed to verbalise exactly how I achieve that in my org This is where I struggle as well.
- NAHWheatCracker 3y ago
  It's often not a matter of verbalizing if the decision makers don't want to believe what you're saying. You have to be working with people who are more interested in finding the best outcome for the organization/team/people than the most convenient decision for personal or political reasons.
simonw 3y ago
An interesting challenge I've found with the term "technical debt" is that engineers can use it as an excuse to work on all kinds of things that might not genuinely be paying down technical debt, taking advantage of situations where the people making the prioritization decisions don't have the hands-on technical experience of the codebase to evaluate if the proposed "improvement" is a good investment of effort or not. AKA someone needs to be able to push back against "we'll rewrite it in Rust to reduce our technical debt".
- NAHWheatCracker 3y ago
  I've been quite frustrated that the term "technical debt" is so misused. It feels like project managers immediately assume technical debt means "the developer wants to play around". I only use it when it means "the features you want can't be implemented, correctly, and under the time constraints". For what it's worth, I shy away from the term and talk more about approaches and outcomes. It's still baffling when I give a project manager the options: 1. Rewrite and have a working prototype in 2 weeks and solid product in two months. We will be able to use better tech, learn some new things, and the product will match the feature needs. 2. Refactor this month and get the feature you want in a couple months after that. We won't learn as much, but we'll have a cleaner technical product and we'll get some features. 3. Try to implement the feature now. It will be late, broken, and other features will break. We will spend all of next quarter patching it. We won't learn anything new. It will slow us down on the next feature. It's always #3.
  - swatcoder 3y ago
    Some of this is a product of job-hopping culture and of having boom-time teams (technical and management) with too many early-career members. Some of it is also just the perpetual back and forth of competing interests. That said, for those who do good work and develop long-term trust with long-term colleagues, addressing technical debt is often “poke at this while I sip coffee” work that get chipped away at gradually and without a lot of paperwork, or that gets quietly slipped in alongside other feature work. When you’re having to pitch the work to someone, you’ve often already failed the pitch. The debt payment is already due. But if your peers come to trust you, then they learn not to reject a PR that cleaned up this module a little more than strictly necessary or that included a commit that revisited an adjacent abstraction. To get there, though, you need to work on healthy, stable teams with experienced colleagues rather than in the mad churn that seems to dominate a lot of work cultures these days.
    - NAHWheatCracker 3y ago
      > When you’re having to pitch the work to someone, you’ve often already failed the pitch. Damn that stings and it's so true. > But if your peers come to trust you, then they learn not to reject a PR that cleaned up this module a little more than strictly necessary I've never had an issue where a coworker rejected a PR, even when doing a massive refactor that isn't strictly necessary. Project managers are the ones that don't see this kind of work and it's benefits. They're the ones that I find it hard to build trust with.
      - necovek 3y ago
        > I've never had an issue where a coworker rejected a PR, even when doing a massive refactor that isn't strictly necessary. As an engineer, I have rejected massive refactors in unrelated PRs: heck, I have rejected massive PRs period. They always: - are hard to review - bundle a bunch of unrelated changes together - hard to accept piecemal - risky to test and deploy - hard to revert - hard to pivot according to new learnings along the way - hard to improve - have lots of review iterations - slow down all the other work (conflicts, remerging effort for all the other changes in flight...) - usually "one way doors" (relates to hard to revert) When these are done as small incremental steps where we improve one thing at a time, none of the above hold, and coupled with a good CI/CD pipeline, take less time. I know that many engineers believe there are things that can't be done incrementally like that, but I've always been able to give them a plan for any "impossible-to-split" refactor/rewrite.
- lmm 3y ago
  The most effective place I've worked had a fixed allocation to technical debt work (25%) and let engineering agree how to prioritise that. Want to rewrite it in Rust? If you get buy-in from the rest of the technical team to say that that's more important than sorting out the database schema or whatever you can do that, but you'd better be able to do it piece by piece and keep delivering business value the whole time. Theoretically someone who understood both the business and the technical side of things ought to be able to weigh up individual tasks from both sides and figure out which was higher priority. But in practice that seems very hard - you'd need both intimate knowledge of both domains and immunity to organisational politics. Explicitly adjusting that high-level dial (so maybe the 25% becomes 50% when it's a codebase you want to publish/reuse, or 0% when it's an EOL project that you're just running until it falls apart) might be the best you can do in practice.
  - zharknado 3y ago
    Worked in a similar setup as a PM and really liked it. As you said, it can be somewhat apples-to-oranges comparing new functionality with a stream of tech debt opportunities, so it’s helpful to target a ratio, more like stocks/bonds in a portfolio. We called it “product health” so it could encompass tech debt but also UX debt, performance, cosmetics, etc.
- closeparen 3y ago
  Good judgement about how to allocate your time (and the team's) is one of the most important skillsets of a senior or staff-level engineer.
- valenterry 3y ago
  If engineers do that, then they don't need to use the term "technical debt" anyways. They can just claim a feature takes twice as long and then play around 50% of the time. So in reality, it's not "technical debt" that's the issue, it's that engineers don't have the right incentives from the beginning.
- rednafi 3y ago
  Well, when developer productivity is measured against PR rate or number of commits, I guess this is what happens. Also, it’s debatable if someone should be managing a team of engineers if they don’t have a honed bullshit detector to catch this sort of things.

ecfi 3y ago

> So far, I've failed to verbalise exactly how I achieve that in my org This is where I struggle as well.

NAHWheatCracker 3y ago
It's often not a matter of verbalizing if the decision makers don't want to believe what you're saying. You have to be working with people who are more interested in finding the best outcome for the organization/team/people than the most convenient decision for personal or political reasons.

simonw 3y ago

An interesting challenge I've found with the term "technical debt" is that engineers can use it as an excuse to work on all kinds of things that might not genuinely be paying down technical debt, taking advantage of situations where the people making the prioritization decisions don't have the hands-on technical experience of the codebase to evaluate if the proposed "improvement" is a good investment of effort or not. AKA someone needs to be able to push back against "we'll rewrite it in Rust to reduce our technical debt".

NAHWheatCracker 3y ago
I've been quite frustrated that the term "technical debt" is so misused. It feels like project managers immediately assume technical debt means "the developer wants to play around". I only use it when it means "the features you want can't be implemented, correctly, and under the time constraints". For what it's worth, I shy away from the term and talk more about approaches and outcomes. It's still baffling when I give a project manager the options: 1. Rewrite and have a working prototype in 2 weeks and solid product in two months. We will be able to use better tech, learn some new things, and the product will match the feature needs. 2. Refactor this month and get the feature you want in a couple months after that. We won't learn as much, but we'll have a cleaner technical product and we'll get some features. 3. Try to implement the feature now. It will be late, broken, and other features will break. We will spend all of next quarter patching it. We won't learn anything new. It will slow us down on the next feature. It's always #3.
- swatcoder 3y ago
  Some of this is a product of job-hopping culture and of having boom-time teams (technical and management) with too many early-career members. Some of it is also just the perpetual back and forth of competing interests. That said, for those who do good work and develop long-term trust with long-term colleagues, addressing technical debt is often “poke at this while I sip coffee” work that get chipped away at gradually and without a lot of paperwork, or that gets quietly slipped in alongside other feature work. When you’re having to pitch the work to someone, you’ve often already failed the pitch. The debt payment is already due. But if your peers come to trust you, then they learn not to reject a PR that cleaned up this module a little more than strictly necessary or that included a commit that revisited an adjacent abstraction. To get there, though, you need to work on healthy, stable teams with experienced colleagues rather than in the mad churn that seems to dominate a lot of work cultures these days.
  - NAHWheatCracker 3y ago
    > When you’re having to pitch the work to someone, you’ve often already failed the pitch. Damn that stings and it's so true. > But if your peers come to trust you, then they learn not to reject a PR that cleaned up this module a little more than strictly necessary I've never had an issue where a coworker rejected a PR, even when doing a massive refactor that isn't strictly necessary. Project managers are the ones that don't see this kind of work and it's benefits. They're the ones that I find it hard to build trust with.
    - necovek 3y ago
      > I've never had an issue where a coworker rejected a PR, even when doing a massive refactor that isn't strictly necessary. As an engineer, I have rejected massive refactors in unrelated PRs: heck, I have rejected massive PRs period. They always: - are hard to review - bundle a bunch of unrelated changes together - hard to accept piecemal - risky to test and deploy - hard to revert - hard to pivot according to new learnings along the way - hard to improve - have lots of review iterations - slow down all the other work (conflicts, remerging effort for all the other changes in flight...) - usually "one way doors" (relates to hard to revert) When these are done as small incremental steps where we improve one thing at a time, none of the above hold, and coupled with a good CI/CD pipeline, take less time. I know that many engineers believe there are things that can't be done incrementally like that, but I've always been able to give them a plan for any "impossible-to-split" refactor/rewrite.
lmm 3y ago
The most effective place I've worked had a fixed allocation to technical debt work (25%) and let engineering agree how to prioritise that. Want to rewrite it in Rust? If you get buy-in from the rest of the technical team to say that that's more important than sorting out the database schema or whatever you can do that, but you'd better be able to do it piece by piece and keep delivering business value the whole time. Theoretically someone who understood both the business and the technical side of things ought to be able to weigh up individual tasks from both sides and figure out which was higher priority. But in practice that seems very hard - you'd need both intimate knowledge of both domains and immunity to organisational politics. Explicitly adjusting that high-level dial (so maybe the 25% becomes 50% when it's a codebase you want to publish/reuse, or 0% when it's an EOL project that you're just running until it falls apart) might be the best you can do in practice.
- zharknado 3y ago
  Worked in a similar setup as a PM and really liked it. As you said, it can be somewhat apples-to-oranges comparing new functionality with a stream of tech debt opportunities, so it’s helpful to target a ratio, more like stocks/bonds in a portfolio. We called it “product health” so it could encompass tech debt but also UX debt, performance, cosmetics, etc.
closeparen 3y ago
Good judgement about how to allocate your time (and the team's) is one of the most important skillsets of a senior or staff-level engineer.
valenterry 3y ago
If engineers do that, then they don't need to use the term "technical debt" anyways. They can just claim a feature takes twice as long and then play around 50% of the time. So in reality, it's not "technical debt" that's the issue, it's that engineers don't have the right incentives from the beginning.
rednafi 3y ago
Well, when developer productivity is measured against PR rate or number of commits, I guess this is what happens. Also, it’s debatable if someone should be managing a team of engineers if they don’t have a honed bullshit detector to catch this sort of things.