Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reframing Tech Debt

increment.com

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Reframing Tech Debt

#21

Post by Lhiw »

wpietri wrote: post #9

I 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 de…

I've never liked the small slice approach. It's always the first thing to be scope cut whent time is running out.

I prefer to just do refactors before work starts, or during the work itself.

I have run into managers that read how to work with legacy code and think everything we do should be one line changes and major refactors mean we're basically doing rewrites.

I still work there. Sometimes.

Re: Reframing Tech Debt

#23

Post by redroot »

wpietri wrote: post #9

I 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 de…

> I think it's a mistake to ask non-experts to prioritize things they don't understand.

Exactly right, for the most part if the business has enough trust in engineering to do the best they can, the technical strategy to realise business value is up to engineering, including 'debt'.

The most effective strategy I've seen so far is my current employer. We split our time across the quarter. 60% to core product focuses for the quarter, 20% to ad-hoc requests from the business, and 20% to 'tech improvement'. The latter includes personal growth for new engineers related to our stack or exploring new tech, improving our current tooling, and addressing areas of 'tech debt'. This split is agreed with the business, and the tech lead in a team is responsible for maintaining the balance and has autonomy here too - often we see areas of debt that impact our product focuses so that becomes core for example. It takes trust on all sides but seems to be working well.

Re: Reframing Tech Debt

#24

Post by nerdponx »

wpietri wrote: post #9

I 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 de…

> 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.

My experience has been that, once in a while, even this is not enough. You might just get accused of being a perfectionist or being overly meticulous about things that don't matter, and why can't we just do it the easy way and worry about it later?

Of course, if that does happen, it means that you are in a toxic work environment and you need to leave as soon as you can. But it does happen, and I have experienced it firsthand.

Re: Reframing Tech Debt

#25

Post by secondaryacct »

nerdponx wrote: post #24
wpietri wrote: post #9

I 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 de…

> 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. My experience has been that, once in a while, even this is not enough. You might just get accused of being a perfectionist or being overly meticulous about things that don't matter, and why can't we just do it the easy way an…

But you missed his point, it can be negotiated too. You get called a perfectionist because you project you refuse compromises, but have you thought of the business cost of any quality-oriented delay? (the opposite of quality-oriented work is result-oriented work)

Yes doing shit on top of shit will be paid later, but sometimes, maybe that's fine to pay later while you are scrambling to make money in the first place ?

Re: Reframing Tech Debt

#26

Post by convolvatron »

ahdh8f4hf4h8 wrote: post #10
sktrdie wrote: post #7

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 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…

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.

Re: Reframing Tech Debt

#27

Post by secondaryacct »

redroot wrote: post #13
ahdh8f4hf4h8 wrote: post #5

Personally, 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 cod…

I've also found the term quite dangerously misleading. The 'tech' part of the statement makes it sound like the 'debt' that is getting in your way it's purely a concern of the engineering function, where it should be a concern of the business. The 'debt' part is also confusing - I have seen non-technical stakeholders thinking it can be dealt with like financial debt with more revenue or VC rounds in one lump sum, we…

Yes I agree. We get sometimes trapped in fixing well working but awkwardly written features, when the very well written initial assumptions just slow any change much much more visibly, which could actually be fixed by ... a badly written rushed silly code and multiply dev productivity.

So in a way the beauty of the implementation matter a lot less than its ability to change quickly which sounds obvious said like that.

Re: Reframing Tech Debt

#28

Post by analog31 »

Maybe "technical rent" would be a better term, as it implies a recurring cost that's paid to keep something that's already been built. Managers already grasp recurring software costs.

Re: Reframing Tech Debt

#29

Post by lowercased »

redroot wrote: post #13
ahdh8f4hf4h8 wrote: post #5

Personally, 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 cod…

I've also found the term quite dangerously misleading. The 'tech' part of the statement makes it sound like the 'debt' that is getting in your way it's purely a concern of the engineering function, where it should be a concern of the business. The 'debt' part is also confusing - I have seen non-technical stakeholders thinking it can be dealt with like financial debt with more revenue or VC rounds in one lump sum, we…

> For example, baked-in assumptions of how business works in Market A as you are expanding into Market's B and C. This isn't the fault of engineering

And you can bet the farm that some dev (or team) was trying to build in some flexibility in to the models which might have added an extra 2 weeks to deliver, which would save months of re-development a year later, and was shot down with 'YAGNI!' or just... "we don't have time!"

For some reason "management" folks get to plan out for the next 4-8-12 quarters, but a dev putting in basic plumbing to accommodate change that will happen 6-12 months down the road is simply rebuffed. "Oh, developers just want to write stuff all the time, they don't understand business", etc, and other nuggets I've heard over the years - grates me to no end.

Re: Reframing Tech Debt

#30

Post by dpeck »

If you’re getting explicit buy-in from leadership about technical debt you can be assured that whoever was in your role previously failed badly at keeping engineering aligned and in step with the overall goals of the business.
Post reply on HN