We sound like idiots when we talk about technical debt • Hacker News Board

Re: We sound like idiots when we talk about technical debt

#91

Post by lolinder » Thu, Feb 10, 2022, 2:34 PM UTC

adverbly wrote: post #46

wokwokwok wrote: post #20

Controversial idea: Technical debt is something that 'business users' don't need to or want to care about. If you're having conversations about technical debt, you've messed up, and you will continue to have unsatisfactory outcomes until you stop doing so. You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot…

Not sure I agree with the theme of this take. Technical debt can be significant and take months to address on a large codebase. This take also places a lot of blame on the devs who have to work on tech debt, where in reality, it's often another dev who wrote the original code(usually several years ago, and no longer at the company). Things are more complicated than "just deal with it and hide it under a rug".

> Technical debt can be significant and take months to address on a large codebase.

I think the premise is that if you've got months of technical debt built up, you've already screwed up. If you (and everyone else on your team) refuse to ever take shortcuts, you'll end up debt free.

If you're already in a situation where you have mounds of debt, yes, you can't just increase your estimate for current tasks.

Re: We sound like idiots when we talk about technical debt

#92

Post by andrew_ » Thu, Feb 10, 2022, 2:35 PM UTC

catlifeonmars wrote: post #81

Speculation ahead: One cost of accruing tech debt is the toll that it has on the mental health of developers. To me, it seems like common sense that over a certain threshold, unhappy developers will (1) work slower, (2) produce lower quality work, and (3) have a higher rate of turnover. I’m curious if there is any research on this effect (if it exists).

Absolutely agree. I moved on from a very high level engineering position last August for exactly these reasons. A mountain of technical debt the size and breadth of the Rockies that was not being addressed was dragging everyone down. I'd had enough. Leadership at my current position understands what technical debt means, they understand the technical reasons given for calling it such, and the impact not only on business but also development time and DX.

Re: We sound like idiots when we talk about technical debt

#93

Post by andrew_ » Thu, Feb 10, 2022, 2:36 PM UTC

marginalia_nu wrote: post #21

adrianN wrote: post #3

Technical debt and its costs are extremely hard to quantify and saying things like "with 3-6 weeks of engineering time we can cut failures in half" is just inventing numbers to get what you want.

I get that a lot of people in IT are very facts-focused, but if you want to actually convince people that they need to act in some fashion, you need to add some emotional weight to your arguments (pulling numbers out of your ass is one way of doing that). Admit it or not, the reason you want the technical debt addressed is primarily emotional. You are frustrated with how difficult it is to work, you fear for the futu…

In my experience this isn't an issue if there is good leadership in place.

Re: We sound like idiots when we talk about technical debt

#94

Post by taneq » Thu, Feb 10, 2022, 2:40 PM UTC

wokwokwok wrote: post #20

Controversial idea: Technical debt is something that 'business users' don't need to or want to care about. If you're having conversations about technical debt, you've messed up, and you will continue to have unsatisfactory outcomes until you stop doing so. You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot…

> Doing a rubbish job as quickly as you can is not your job. Not ever.

Unfortunately someone else IS willing to do a rubbish job as quickly as they can, look absolutely golden to their managers and clients for a while, then slingshot their career on to the next big pay raise, leaving the next poor chump to take the fall for their malfeasance.

Re: We sound like idiots when we talk about technical debt

#95

Post by verve_rat » Thu, Feb 10, 2022, 2:40 PM UTC

magicalhippo wrote: post #16

EarthLaunch wrote: post #8

Usually it's hard to quantify technical debt. And anyway, when debt is first accumulated, it has no downsides. When you first take out a loan, you don't pay anything for the first month. Without understanding the long term nature of debt and interest, you will see it as free money. Business leaders have wisely learned how finances work, and financial debt. We need to learn how software engineering works, and technica…

A better term might be "technical mass". Having lots of it makes it harder to quickly implement changes and features. It would also better cover the fact that work must be done to get rid of the excess mass. Calling it debt might undersell how easy it is to get rid of it. Though if business folks didn't take physics classes it might not resonate well with them.

I like that. More mass slows everything down and makes changing direction harder.

Re: We sound like idiots when we talk about technical debt

#96

Post by speed_spread » Thu, Feb 10, 2022, 2:41 PM UTC

wokwokwok wrote: post #20

Controversial idea: Technical debt is something that 'business users' don't need to or want to care about. If you're having conversations about technical debt, you've messed up, and you will continue to have unsatisfactory outcomes until you stop doing so. You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot…

While I agree with this idealistic view, all it takes is one delusional, misinformed or ambitious EM to break rank and start cutting corners for short term wins with the management and before you know it all teams are now expected to do the same.

Any organization where management does not readily acknowledge their reliance on technology and its associated upkeep costs is doomed to eventually sink waist deep in a tech mud pool of their own making.

Re: We sound like idiots when we talk about technical debt

#97

Post by perrygeo » Thu, Feb 10, 2022, 2:42 PM UTC

drcongo wrote: post #5

k__ wrote: post #2

Usually, the discussion goes the other way around. Product is pissed because delivery is stagnated and that's because of technical debt. Product: We need that change for Big Co. Techie: Okay, that takes two weeks. Product: Two weeks? For such a small change?? Techie: Yes, because we are drowing in technical debt and you're priorizing features and not maintanence. Also, usually techies don't care. Why? Because it's al…

Yeah, I didn't find the intro conversation in the article familiar at all. And also, if a one day change is taking a week then when asked "Oh really! What is it costing us?" the answer is 5x what it should. It's incredibly easy to directly link technical debt to running costs.

Exactly this. The author's dev-blaming perspective is that Tech Debt costs are not accounted for systematically nor communicated clearly to the business folks.

Yet the intro provides an example of clearly quantifying and communicating the costs. I'd say he disproves his own point in the introduction. I found it hard to read the rest of this article.

Re: We sound like idiots when we talk about technical debt

#98

Post by troebr » Thu, Feb 10, 2022, 2:45 PM UTC

davewritescode wrote: post #35

adrianN wrote: post #3

Technical debt and its costs are extremely hard to quantify and saying things like "with 3-6 weeks of engineering time we can cut failures in half" is just inventing numbers to get what you want.

I had a conversation that stuck with me a few years ago at a very large company about making proposals for future projects. I had a habit of making very detailed proposals, doing a great job making projections and being accurate about those projections. A VP of engineering pulled me aside after he saw that one of my proposals wasn’t getting traction and told me “None of the people who are writing alternatives to your…

It's what product is doing anyway, numbers are so often just made up to support a narrative.

Re: We sound like idiots when we talk about technical debt

#99

Post by lhnz » Thu, Feb 10, 2022, 2:45 PM UTC

samhw wrote: post #78

EugeneOZ wrote: post #75

Earlier quoted context omitted.

And you are working alone and on the new codebases only and your code is perfect from the beginning and you are not discovering better ways with time. I got it ;)

These are the people we avoid like the plague when hiring: people who are obsessed with the intrinsic beauty of their code, rather than its business utility. They're welcome to do that with their own code in their own time (and many people like to do that, quite understandably), but it's toxic in any sort of business environment. You need to be able to make practical judgements about how much time to invest in, say,…

To be fair, as we are aiming to become better software engineers, on every PR we make, we should be aiming to decrease our bug rate, and increase our speed, testing, robustness, performance and the overall expressiveness.

Why don't you "simply write code faster with fewer bugs" seems sarcastic or unrealistic (or Übermensch) but over time with practice we should attempt to do this. And I do see it, within the practices of the top software engineers on GitHub, who often write better quality code than I could faster than I could. It must be achievable.

Re: We sound like idiots when we talk about technical debt

#100

Post by samhw » Thu, Feb 10, 2022, 2:52 PM UTC

EugeneOZ wrote: post #80

samhw wrote: post #78

Earlier quoted context omitted.

These are the people we avoid like the plague when hiring: people who are obsessed with the intrinsic beauty of their code, rather than its business utility. They're welcome to do that with their own code in their own time (and many people like to do that, quite understandably), but it's toxic in any sort of business environment. You need to be able to make practical judgements about how much time to invest in, say,…

We were talking about another topic. “Temporary dirty MVPs” are only acceptable if their code will be completely thrown away. Otherwise, “there is nothing more permanent than temporary patches” (c) forgot who.

Yeah, certainly the tech debt code should be thrown away. I think this is hard to discuss without a concrete example in mind, though. Or rather without both having the same concrete example in mind.

I get the sense that everyone here is imagining their own - very different - concrete example of tech debt, and talking entirely at cross purposes as a result.