5 ms·

My experience at big corporate is that (edit: unmanageable) tech debt is caused by undisciplined and unorganized scrum team. When you have a proper backlog of

My experience at big corporate is that (edit: unmanageable) tech debt is caused by undisciplined and unorganized scrum team. When you have a proper backlog of tickets, including tech debt tickets, the team will eventually fix the tech debt when there are not enough feature tickets to exhaust capacity.

deknos 2y ago
if tech debt would depend on some kind of methodology it would not pop up with XP/Kanban/waterfall. techdebt can even pop up in unorganized slowmo opensource software.
loloquwowndueo 2y ago
“Not enough feature tickets to exhaust capacity” - I don’t think I’ve ever seen this happen :) PMs and sales always manage to book all available capacity.
- hinkley 2y ago
  I’ve done it once or twice. One particular time there was a lot of hand wringing about how there was nothing to work on. I about saw red. Tech debt and bugs. That’s what you work on. That incident really changed my perspective on people who talk about how tech debt is bad. Some of them will roll up their sleeves, but some just want to look high minded without putting in the effort.
bbojan 2y ago
> the team will eventually fix the tech debt when there are not enough feature tickets to exhaust capacity I have yet to visit this misterious universe you describe.
- Swizec 2y ago
  > I have yet to visit this misterious universe you describe. The trick is to have 1 backlog. Tech debt and features live on the same list and it is up to the PM to prioritize. Engineering’s job is to argue cost. Good PMs will prioritize relevant tech debt or pull it in with feature work in the same area. They understand the tradeoff of go slow to go fast. They also understand when tech debt will never become relevant (because the feature is getting nixed, or hasn’t shown desired impact yet, or because the cost of interest is waaaay lower than the cost of paying it off in many cases). This only works when engineers have the discipline to look stinky awful code in the eye and say “not today” and stay within agreed timeboxes. You blow this estimate once or twice, get the PM in hot water with leadership, and you’ve lost the trust.
  - NAHWheatCracker 2y ago
    All of the teams I've been on have used one list. I've never seen a PM prioritize the technical work. I still think it's a good idea for it to be one list, but it's not sufficient. For teams that don't have a good PM, you also need a tech champion. Failing that, engineers need to inflate estimates and do tech work under other stories. Then everything becomes less predictable and teams never develop trust.
    - Swizec 2y ago
      > For teams that don't have a good PM, you also need a tech champion Yes. And to add some nuance, you need a [trusted] engineer who can say “This will take 3 weeks because of tech debt items A, B, C. We can fix those in 1 week and then take 1 week to implement this. How would you like to proceed?” Any decent PM will take the 2 week option that also cleans up the codebase. But if fixing the tech debt would take 3 weeks and then another 2 weeks to build the feature, then any decent PM will take the option that doesn’t fix tech debt unless there’s a bunch more stuff coming in this area in which case taking 3 weeks to fix stuff is totally worth it. Their job is to make those tradeoffs. Our job is to highlight the tradeoffs they’re making so they can make informed decisions.
      - NAHWheatCracker 2y ago
        I agree with you completely that you need trust. > Our job is to highlight the tradeoffs they’re making so they can make informed decisions. This is an oft-stated thing that I oft-disagree with. It states that engineers ought to be subordinate to PMs, which shouldn't always be the case. If you have shit engineers and great PMs, the best outcome is likely to shift decision making to PMs. If you have great engineers and shit PMs, decision making should shift towards engineers. If they are both equivalently shit or great, it should be a balance. I believe this is the most likely scenario. I believe that balance is thrown out the window if engineers "highlight the tradeoffs" while the actual decision making is lies with the PMs. How to actually achieve balance is extremely idiomatic to the team and organization. It's hard to get people to have adult, non-confrontational discussions about this sort of thing, however. Too many people will treat it as a negotiation.
- xarope 2y ago
  you need a smart PM who works closely with the CTO to craft the narrative to sales, that the next critical feature milestone is gated behind fixing said tech debt...
- hinkley 2y ago
  I and one, maybe two other coworkers will fix some of the tech debt while everyone else tries to avoid making eye contact, and we fantasize about a world where voodoo dolls actually work.
- jakjak123 2y ago
  Me too. I have never seen this world
arrjayh 2y ago
> My experience at big corporate is that (edit: unmanageable) tech debt is caused by undisciplined and unorganized scrum team. Yeah, this is 100% correct. I comically left Riot after ~6 months for this exact reason. Obviously it's a large company with many different flavors of teams, and it sounds like this team maybe has gotten it together, but by in large most haven't. While I was there I was working on some of their core games tooling and felt uneasy about my day-to-day. My teams tech debt was quite literally owning them. Constantly missing sprint scopes, spending countless hours arguing and debating about trivial stuff, it was all a mess. They ended up laying off a number of people from that team in a pretty shifty manner so maybe things have gotten better since then.
- intelVISA 2y ago
  What was the rough team composition?
  - arrjayh 2y ago
    ~20 engineers, ~3 people managers. From what I recall the team had high attrition and shuffled through a number of people managers. When I joined 1 manager was new hire, 1 manager was new-ish hire, 1 manager was fairly seasoned at Riot and had a "good reputation". Was still a total mess.
rqmedes 2y ago
Agile is perfectly optimised for creating tech debt. Corporate software is almost always impossible to change once released so it’s obvious that frequent iterative deliverables that you can only code around or on top of propagate technical debt
- hinkley 2y ago
  Waterfall has time to bury the debt and let the grass grow over the crime scene before people come asking questions. This is dev culture not agile culture.
pjc50 2y ago
> not enough feature tickets to exhaust capacity This puts you at grave risk of redundancies.

deknos 2y ago

if tech debt would depend on some kind of methodology it would not pop up with XP/Kanban/waterfall. techdebt can even pop up in unorganized slowmo opensource software.

loloquwowndueo 2y ago

“Not enough feature tickets to exhaust capacity” - I don’t think I’ve ever seen this happen :) PMs and sales always manage to book all available capacity.

hinkley 2y ago
I’ve done it once or twice. One particular time there was a lot of hand wringing about how there was nothing to work on. I about saw red. Tech debt and bugs. That’s what you work on. That incident really changed my perspective on people who talk about how tech debt is bad. Some of them will roll up their sleeves, but some just want to look high minded without putting in the effort.

bbojan 2y ago

> the team will eventually fix the tech debt when there are not enough feature tickets to exhaust capacity I have yet to visit this misterious universe you describe.

Swizec 2y ago
> I have yet to visit this misterious universe you describe. The trick is to have 1 backlog. Tech debt and features live on the same list and it is up to the PM to prioritize. Engineering’s job is to argue cost. Good PMs will prioritize relevant tech debt or pull it in with feature work in the same area. They understand the tradeoff of go slow to go fast. They also understand when tech debt will never become relevant (because the feature is getting nixed, or hasn’t shown desired impact yet, or because the cost of interest is waaaay lower than the cost of paying it off in many cases). This only works when engineers have the discipline to look stinky awful code in the eye and say “not today” and stay within agreed timeboxes. You blow this estimate once or twice, get the PM in hot water with leadership, and you’ve lost the trust.
- NAHWheatCracker 2y ago
  All of the teams I've been on have used one list. I've never seen a PM prioritize the technical work. I still think it's a good idea for it to be one list, but it's not sufficient. For teams that don't have a good PM, you also need a tech champion. Failing that, engineers need to inflate estimates and do tech work under other stories. Then everything becomes less predictable and teams never develop trust.
  - Swizec 2y ago
    > For teams that don't have a good PM, you also need a tech champion Yes. And to add some nuance, you need a [trusted] engineer who can say “This will take 3 weeks because of tech debt items A, B, C. We can fix those in 1 week and then take 1 week to implement this. How would you like to proceed?” Any decent PM will take the 2 week option that also cleans up the codebase. But if fixing the tech debt would take 3 weeks and then another 2 weeks to build the feature, then any decent PM will take the option that doesn’t fix tech debt unless there’s a bunch more stuff coming in this area in which case taking 3 weeks to fix stuff is totally worth it. Their job is to make those tradeoffs. Our job is to highlight the tradeoffs they’re making so they can make informed decisions.
    - NAHWheatCracker 2y ago
      I agree with you completely that you need trust. > Our job is to highlight the tradeoffs they’re making so they can make informed decisions. This is an oft-stated thing that I oft-disagree with. It states that engineers ought to be subordinate to PMs, which shouldn't always be the case. If you have shit engineers and great PMs, the best outcome is likely to shift decision making to PMs. If you have great engineers and shit PMs, decision making should shift towards engineers. If they are both equivalently shit or great, it should be a balance. I believe this is the most likely scenario. I believe that balance is thrown out the window if engineers "highlight the tradeoffs" while the actual decision making is lies with the PMs. How to actually achieve balance is extremely idiomatic to the team and organization. It's hard to get people to have adult, non-confrontational discussions about this sort of thing, however. Too many people will treat it as a negotiation.
xarope 2y ago
you need a smart PM who works closely with the CTO to craft the narrative to sales, that the next critical feature milestone is gated behind fixing said tech debt...
hinkley 2y ago
I and one, maybe two other coworkers will fix some of the tech debt while everyone else tries to avoid making eye contact, and we fantasize about a world where voodoo dolls actually work.
jakjak123 2y ago
Me too. I have never seen this world

arrjayh 2y ago

> My experience at big corporate is that (edit: unmanageable) tech debt is caused by undisciplined and unorganized scrum team. Yeah, this is 100% correct. I comically left Riot after ~6 months for this exact reason. Obviously it's a large company with many different flavors of teams, and it sounds like this team maybe has gotten it together, but by in large most haven't. While I was there I was working on some of their core games tooling and felt uneasy about my day-to-day. My teams tech debt was quite literally owning them. Constantly missing sprint scopes, spending countless hours arguing and debating about trivial stuff, it was all a mess. They ended up laying off a number of people from that team in a pretty shifty manner so maybe things have gotten better since then.

intelVISA 2y ago
What was the rough team composition?
- arrjayh 2y ago
  ~20 engineers, ~3 people managers. From what I recall the team had high attrition and shuffled through a number of people managers. When I joined 1 manager was new hire, 1 manager was new-ish hire, 1 manager was fairly seasoned at Riot and had a "good reputation". Was still a total mess.

rqmedes 2y ago

Agile is perfectly optimised for creating tech debt. Corporate software is almost always impossible to change once released so it’s obvious that frequent iterative deliverables that you can only code around or on top of propagate technical debt

hinkley 2y ago
Waterfall has time to bury the debt and let the grass grow over the crime scene before people come asking questions. This is dev culture not agile culture.

pjc50 2y ago

> not enough feature tickets to exhaust capacity This puts you at grave risk of redundancies.