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

51–59 of 59 posts

Re: Reframing Tech Debt

#51

Post by wpietri »

KronisLV wrote: post #43
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…

> That should just be part of the deal; any exceptions should be temporary and carefully negotiated. This feels like it's probably dependent on the culture in question. Writing tests, caring about readability and the long term sustainability of the codebase and even managing the technical debt all can be the exceptions themselves in certain teams. Sure, you can turn around and run for the hills, but for many there, t…

I grant that many people put up with these things. But I also believe many more put up with them than really have to.

In the end, developers have to decide if they're professionals or not. Me, I think of myself like a doctor or a lawyer or an engineer. That means I have a code of ethics and professional duties. As an example, the IEEE/ACM software code of ethics is here: https://ethics.acm.org/code-of-ethics/software-engineering-c...

It's also reasonable if people think of themselves like a minion or a servant, where they're going to do what the boss says, no matter how dumb, dangerous, or counterproductive is. In which case, sure, they can excuse themselves from this discussion of how to manage tech debt, because they've decided to put that power in the hands of others.

But if they are professionals, then this indicates a good place to start:

> Why are you suggesting estimates that are 1.5x - 2x higher than the rest of the team?

Any improvement in working conditions is best achieved through collective action. That is a great moment to talk to team members about setting joint standards for estimates. And one doesn't have to approach it from a highfalutin' perspective of ethics. If colleagues lowball estimates out of ignorance or while seeking glory, that means they're just screwing over the rest of the people on their team.

Which leads me to this:

> those are the circumstances that they put up with to get food on the table

This week, sure. Not everybody can just walk out the door this moment. But over the next 5 years? Every single working developer can have a plan to get more autonomy and better working conditions. Including by building up enough of a cash buffer that they aren't one disagreement with the boss away from not being able to put food on the table.

Indeed, I think it's vital that they do. If they instead just bump along at a job with outdated tech and high debt levels, how easy do they think it will be to get jobs later in life? The skills and habits one builds while working in that sort of swamp don't look great in interviews.

Re: Reframing Tech Debt

#52

Post by wpietri »

bern4444 wrote: post #34
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…

What makes this work is the PM stopped asking about it and let you do it. They stayed focused on the deliverable work and gave you and the team the freedom to work on these tasks as you saw fit. It wasn't squeezed in only when there was room in the sprint, it may not have even been a formal part of the sprint to begin with. The PM wasn't trying to fill up the entire sprint with everything they could fit that they wan…

With that specific PM, we did daily standups the whole time. The problem is not the meeting format, it's letting a product manager think they're in charge of the technical work. You can't let them think they get to boss individuals around or decide how much work fits in a given time or what language you use.

Will product managers want to do more than is professionally responsible or even possible? Sure. It's their job to want things. Will some people try to get up in your business inappropriately? Also yes. But the answer to that is to set clear boundaries. Product people make product decisions. Technical people make technical decisions. And technical people need to be ready to answer in business terms why particular choices are optimal for the business. As well as being able to self-run the technical team so that others don't feel obliged to step into a power vacuum.

Re: Reframing Tech Debt

#53

Post by Viliam1234 »

KronisLV wrote: post #43
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…

> That should just be part of the deal; any exceptions should be temporary and carefully negotiated. This feels like it's probably dependent on the culture in question. Writing tests, caring about readability and the long term sustainability of the codebase and even managing the technical debt all can be the exceptions themselves in certain teams. Sure, you can turn around and run for the hills, but for many there, t…

> This feels like it's probably dependent on the culture in question. Writing tests, caring about readability and the long term sustainability of the codebase and even managing the technical debt all can be the exceptions themselves in certain teams.

I worked in a team that had great culture in this regard. Writing tests, code review, and refactoring were considered an inseparable part of every task; when you estimated the task, you estimated how much this all together would take. The task was considered complete when the comments in code review were fully addressed.

This worked well while we had a manager who was not a developer. He asked for estimates, we gave them, we delivered a product in much higher quality than was typical in the company, he was happy.

Then we got a manager who was also a part-time developer (for another team). And he started asking questions like: "Why did you guys estimate this task to take two days? I could write it in 20 lines of code, why should writing 20 lines of code take two days?" "Well, we also need to consider this, and then we need to write a unit test for this and a unit test for that, and..." "No guys, you don't. Do not overcomplicate things, just do the simplest thing that works." -- I don't know what happened with the project later, because gradually all the original team members have quit.

So, there are ways to address technical debt, and some of them do not require involving the management in too much details, but you still need some minimal level of cooperation from the management; at least on the level of "if the results are consistently ok, I will not needlessly interfere with the details just because I can".

Re: Reframing Tech Debt

#54

Post by bern4444 »

wpietri wrote: post #52
bern4444 wrote: post #34

Earlier quoted context omitted.

What makes this work is the PM stopped asking about it and let you do it. They stayed focused on the deliverable work and gave you and the team the freedom to work on these tasks as you saw fit. It wasn't squeezed in only when there was room in the sprint, it may not have even been a formal part of the sprint to begin with. The PM wasn't trying to fill up the entire sprint with everything they could fit that they wan…

With that specific PM, we did daily standups the whole time. The problem is not the meeting format, it's letting a product manager think they're in charge of the technical work. You can't let them think they get to boss individuals around or decide how much work fits in a given time or what language you use. Will product managers want to do more than is professionally responsible or even possible? Sure. It's their jo…

Totally, it's the separation of boundaries. My current company does this a lot better. My previous company the PMs definitely micromanaged the engineering teams

Re: Reframing Tech Debt

#55

Post by wpietri »

twblalock wrote: post #31
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…

This depends on where the debt is. If it's in the codebase for a single project, then sure, you can do some refactoring while you work, add more tests, etc. It's not too big of a time sink if you do a little at a time, and you can do it all by yourself. But if the tech debt is in the architecture, or the API spec, or the authentication layer, or in some other area that impacts how services owned by multiple teams com…

I agree coordination is needed for cross-team work, but why must that involve people on the product side of the house? In the same way a team can internally prioritize particular technical work, the technical people can coordinate between teams.

I agree that if a mess is particular large, or cleaning it up will have product/schedule impact, sure, the you have to talk with the product people. But the converse it true: if you can find ways to do the necessary technical stuff while still producing sufficient business value, then the product people will never notice.

Re: Reframing Tech Debt

#56

Post by wpietri »

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…

Sure! I definitely get that. And then you have to have the conversations with stakeholders about why best practices are actually best. And those conversations have to be had in business terms. E.g.: https://www.infoq.com/news/2010/03/code-quality-cost-mapping...

It's also possible to be both meticulous and flexible. Sometimes when I've gotten that "can we worry about it later" question, I'll tell them yes. If we have a big external deadline or something, I'm happy to treat tech debt like a high-interest credit card. We run up the bill in an emergency, and then as soon as the emergency's over, we pay off the credit card.

Re: Reframing Tech Debt

#57

Post by wpietri »

redroot wrote: post #23
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 fo…

For sure. And for me, key to making this strategy work is delivering early and often in ways that build confidence. E.g., your 20% ad-hoc requests is a great way to keep unplanned, urgent work from eating up the time necessary tech stuff.

Re: Reframing Tech Debt

#58

Post by wpietri »

bern4444 wrote: post #54
wpietri wrote: post #52

Earlier quoted context omitted.

With that specific PM, we did daily standups the whole time. The problem is not the meeting format, it's letting a product manager think they're in charge of the technical work. You can't let them think they get to boss individuals around or decide how much work fits in a given time or what language you use. Will product managers want to do more than is professionally responsible or even possible? Sure. It's their jo…

Totally, it's the separation of boundaries. My current company does this a lot better. My previous company the PMs definitely micromanaged the engineering teams

Glad to hear you're in a better place!

Re: Reframing Tech Debt

#59

Post by wellpast »

sirwhinesalot wrote: post #47
wellpast wrote: post #17

“Tech debt” is the software industry’s way of euphemistically describing their incompetence. It’s a way to act like one “meant” to implement a shitty architecture instead of admitting one’s lack of ability and experience. It’s the mantra of the expert beginner of which there are so many. You think I’m wrong, but you know I’m right because you can’t define it with any precision no matter how hard you try.

PM: "We promised higher management that feature X would be done by The Date(tm)" DEV: "We can only do that by cutting corners, reusing code for purposes we shouldn't, and making it not extensible in the future" PM" "Yeah but we promised higher management so it needs to get done" some time later... PM: "Hey can we add feature Y by The Date(tm)" DEV: "It doesn't fit with the rushed work we did for feature X, we'll need…

> DEV: "We can only do that by cutting corners, reusing code for purposes we shouldn't, and making it not extensible in the future"

This is an inexperienced dev talking. If s/he was more self-aware, it would be

DEV: I'm not very good at architecture so whatever date you need it by I'm probably going to make a relative mess of it. If you give me more time, at least my rate of introducing mess into the codebase will slow down, so there would be _that_.

Post reply on HN