Reframing Tech Debt
increment.com
Reframing Tech Debt
1–10 of 59 posts
Re: Reframing Tech Debt
#2I like it. I’ve also found success as framing it as building tech capability. Focusing people on adding capability or wealth, positive connotations, I think is the way to go.
Re: Reframing Tech Debt
#3I don't know if I like this framing at all. If your company has fostered an atmosphere where there seems to be tension between writing unit tests and shipping features, you've already screwed it up. If you divide your development schedule between shipping features and writing tests you are simply enabling the bad actors in your organization to inevitably short-change that part of the cycle.
Re: Reframing Tech Debt
#4I’ve worked on a team that explicitly aimed to budget about 10-20% of its time on “tech investment” projects to expand/protect our capability to deliver. We also delivered fairly predictably on business goals. It was glorious.
Re: Reframing Tech Debt
#5Personally, I no longer use the phrase "technical debt" when speaking to management. It's just too vague of a term. Instead I just explain the actual problem and the consequences - too much near duplicate code leading to slow maintenance, non-scalable design choices leading to slow processes, rigid design choices which hamper the team from implementing the upcoming stories, excessive complexity leading making the code hard to change.
Once you get our of analogies and into actual problems, then you can have a reasonable discussion about future tradeoffs. I find even with non-technical managers, debt/wealth is just not a good analogy for code.
Also, often poor code is just part of a larger process problem. You really need to optimize for the whole project, not just code-level to improve the situation.
Re: Reframing Tech Debt
#6I've found most "tech debt" planning to be incredibly vague and nebulous. Many engineers can identify what makes them uncomfortable, but it takes real effort to fully explain why, and what the real impacts are.
Maybe trying to think about "tech wealth" or "tech capability" might change this. Instead of a ticket to "improve error handling" it's "ensure the system can recover from a DNS failure safely to the DB without manual intervention". This sounds more like a feature, because, well, it is.
I've found most of the places talk a lot about having good quality, but few actually did anything concrete about it. Most changes ended up not making any impact. And this is over the course of a 20 year career.
Re: Reframing Tech Debt
#7I'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?
Re: Reframing Tech Debt
#8I'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 beca…
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.
Re: Reframing Tech Debt
#9I think this is a mistake a lot of people make:
> Carving out time to pay down tech debt requires buy-in from leadership.
Not in my experience! I think one can do pretty well a) refusing to put debt in to begin with, and b) for any new work, including necessary cleanup of what you'll be touching in the estimates.
Some years back I had an explicit understanding with a product manager: the engineers would track tech debt and take care of it in small slices over time. He could always ask for details, but absent his curiosity, we'd just leave him out of it, doing a little bit every week so that things always stayed in good enough shape that we would keep our velocity high and our surprises low. Early on he asked a couple of times, but he quickly realized that to him it was entirely boring.
I think it's a mistake to ask non-experts to prioritize things they don't understand. You're not going to ask your execs if it's ok for you to take time to eat or brush your teeth. You equally shouldn't ask them if it's ok to be a responsible professional and do things like writing tests and keeping the code base reasonably clean. That should just be part of the deal; any exceptions should be temporary and carefully negotiated.
Re: Reframing Tech Debt
#10I'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 beca…
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.