4 ms·

I'm curious how largish software projects are organized to deal with tech debt. Is it just ingrained and taken into account for say 20% of the work at each spri

I'm curious how largish software projects are organized to deal with tech debt. Is it just ingrained and taken into account for say 20% of the work at each sprint planning? Is there a specific team dedicated to doing tech debt stuff? Do people just work on tech debt when they feel like it? Are there just a few people in the team that like to go around the project and take on smallish tech debt tasks? I'm curious because our team is struggling with tech debt. We are divided in feature teams and I had this idea of maybe simply having a "tech debt team" that, just like feature teams, has sprints achieving tech-debt related goals such as "improve startup times by 10%" or "decouple router module from auth module" or "setup webpack to tree-shake modules" etc. How do y'all do it?

taeric 5y ago
I've rarely seen directly working on tech debt actually pay off. You either get stuck fixing last year's problem, or you lose the race to feature parity with where you were. To that end, keep cleaning as you go. And accept that good development can be like a good batter. Probabilistically good. Not certain.
ahdh8f4hf4h8 5y ago
I have always done "just in time" refactoring - when a big change comes to a module and you're going to have to re-test most of it anyways, then perform the refactor, test the code/module, and then implement the actual change. It helps if you have some long term vision for the product, so you have some idea of future changes as well. You want to avoid refactoring if no one else is going to test the change, or if your automated test coverage on the module isn't too good. It's too easy to introduce changes that won't be noticed before deployment. Chances are most code already works well enough even if the design or code is suboptimal - often the system only changes in certain parts and changes there often. If you can identify the parts of your system that are likely to change due to changes in scale or business requirement, than that is a natural area to focus on in future redesigns or refactoring.
- convolvatron 5y ago
  this is right. in particular its timely and easy to justify if you can reasonably argue that new priority work would benefit from the refactoring of adjacent components.
wpietri 5y ago
> I had this idea of maybe simply having a "tech debt team" Please don't do this. If it's one team's job to clean up the messes other teams leave, you've created a terrible incentive for other teams around working clean. I remember one place where each project had a fixed-in-advance schedule and engineers were rotated among projects based on whoever was available when the project officially started. Since people rarely worked in the same area of the code base from project to project, the incentive was to get something working and then GTFO. The code of course got steadily worse. So then the company would compensate with major rewrites of the most garbage-y sections.

taeric 5y ago

I've rarely seen directly working on tech debt actually pay off. You either get stuck fixing last year's problem, or you lose the race to feature parity with where you were. To that end, keep cleaning as you go. And accept that good development can be like a good batter. Probabilistically good. Not certain.

ahdh8f4hf4h8 5y ago

I have always done "just in time" refactoring - when a big change comes to a module and you're going to have to re-test most of it anyways, then perform the refactor, test the code/module, and then implement the actual change. It helps if you have some long term vision for the product, so you have some idea of future changes as well. You want to avoid refactoring if no one else is going to test the change, or if your automated test coverage on the module isn't too good. It's too easy to introduce changes that won't be noticed before deployment. Chances are most code already works well enough even if the design or code is suboptimal - often the system only changes in certain parts and changes there often. If you can identify the parts of your system that are likely to change due to changes in scale or business requirement, than that is a natural area to focus on in future redesigns or refactoring.

convolvatron 5y ago
this is right. in particular its timely and easy to justify if you can reasonably argue that new priority work would benefit from the refactoring of adjacent components.

wpietri 5y ago

> I had this idea of maybe simply having a "tech debt team" Please don't do this. If it's one team's job to clean up the messes other teams leave, you've created a terrible incentive for other teams around working clean. I remember one place where each project had a fixed-in-advance schedule and engineers were rotated among projects based on whoever was available when the project officially started. Since people rarely worked in the same area of the code base from project to project, the incentive was to get something working and then GTFO. The code of course got steadily worse. So then the company would compensate with major rewrites of the most garbage-y sections.