Live data from Hacker News

We sound like idiots when we talk about technical debt

cyclic.sh

111–120 of 198 posts

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

#111
post #68
post #54

Earlier quoted context omitted.

It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand .

For sure! And most of the time I would say spending 20x the time on a thing that you have no flipping idea is going to land is worse than technical debt, its called closing your doors. I just wanted to call out the posters who blame individual eng for the product quality, they've either never worked in a toxic org or are helping be the source!

Ah, yeah, I absolutely agree with you in that case. That's a very fair point. I'm sure there are lots of companies in which context it's not the engineer's decision at all, and therefore not their fault.

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

#112

If the contractor finds asbestos, he's allowed to quote me more to do the work I hired him for. If my mechanic says my car has old parts not in inventory, they may cost more and take longer to replace or maybe they charge more to do the work. When the laws change, your lawyer gets billed to review and update your contracts. As new legal precedents are formed, new legalese is created and updated and contracts are rene…

I am not sure that your metaphors actually work when talking about "Technical Debt" in the IT sense of the word.

- If the contractor finds asbestos *which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"...

- If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future...

- If the lawyer who was originally part of the team that helped draft the old law...

etc.

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

#113

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…

> Instead, say: this is how long it will take to do.

You'd better have Nostradamus-level prediction accuracy if you're going to play chicken like that with every estimate you're pressured to give.

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

#114

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…

> 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 pick 'slow and careful', because that's not their job; their job is to quickly deliver value/outcomes/whatever.

That sounds a little crazy. If you applied this same argument to money, you'd conclude that their job is to spend money as fast as possible in order to deliver value, and the debt that builds up is accounting's problem, not theirs. No successful business works like this, so clearly the logic does work if it's presented correctly.

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

#115
post #105
post #99

Earlier quoted context omitted.

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

I'd agree with this, but this is orthogonal to tech debt IMO. Tech debt is a trade-off of a simpler / less extensible implementation in exchange for faster product / business validation of experimental (in some sense) code. It doesn't matter how fast the individual developer is: all that matters is that, where T is some arbitrary unit of execution speed, the simple solution takes e.g. 1T and the more future-proofed s…

^ I thought I should clarify: the reason I'm making the point about relative deltas in speed is that many people ITT seem to think they can leapfrog the tricky question of tech debt by just saying "well, we should all be better engineers, and then we'd write the better-of-the-two implementation more quickly".

And that's just not so. It doesn't matter how fast or quick-minded the engineer is in absolute terms. I've worked with some of the best engineers in the world, and they still took on tech debt (albeit in an intelligent and considered way), because simpler solutions are still faster in relative terms.

Tech debt will forever be a rational choice so long as there's a comparative advantage - so to speak - in taking the simpler path.

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

#116
I think the metaphor for technical debt is leaky, but I don't think engineers sound like idiots when using it. The bigger problem, as I see it, is that so much of the technical organizations in the world are run by non-technical people who often use a top-down approach. Much of the technical debt is created, not due to "rushing things", but rather that there was insufficient problem analysis and solution design prior to writing code, because the top-down approach encourages authoritative statements of intent without enough detail, and each successive layer has to fill in those details with best guesses, any time the guess is wrong technical debt gets created. There are two ways I've seen technical debt addressed successfully in a fairly long (~18 years) career:

1. Technical founder-led companies which have enough technical understanding to have a realistic conversation with engineering leaders and make a decision as to how to approach the problem space to balance time to market vs quality of abstractions.

2. Developers with high autonomy who can set their own timelines as long as features are delivered in expected form. In this case, the timeline can simply encompass either resolving previous technical debt or be extended so that there is enough problem analysis time to prevent the accrual of technical debt in the first place, as long as the feature works as expected at the end, but it's on the developer to deliver to expectations that may not be fully defined. These are usually organizations where engineering has high political capital as department, but the larger business treats it as high magic.

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

#117
post #89

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…

One thing missing from your statement is that plenty of technical-debt comes from things that were done properly the first time , but since then assumptions have changed, or the business is different, or the customer's expectations have evolved, or a competitor has upped their game, etc. This makes the so called perfect solution then, imperfect now - i.e. technical debt. There are always trade-offs, and a good partne…

> since then assumptions have changed, or the business is different, or the customer's expectations have evolved

Hilarious. In the IT department(s) of my Fortune 150, they still do picture-perfect waterfall development, with outsourced teams, writing Java. The application is set in stone when it is signed off in production. Things change? NEW PROJECT. Another 3 YEAR CONTRACT please.

And, yes, as as matter of fact, it IS utterly maddening to be one of the few people who bother to try to say things could be different, and watching nothing change, because so many people's jobs are literally built on their world working this way.

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

#118
post #100

Earlier quoted context omitted.

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.

If the foundation, base of the project is quickly created just for MVP - it should be rewritten. If just some of the small parts were created without care - then throwing them away is not a problem.

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

#119
post #112

If the contractor finds asbestos, he's allowed to quote me more to do the work I hired him for. If my mechanic says my car has old parts not in inventory, they may cost more and take longer to replace or maybe they charge more to do the work. When the laws change, your lawyer gets billed to review and update your contracts. As new legal precedents are formed, new legalese is created and updated and contracts are rene…

I am not sure that your metaphors actually work when talking about "Technical Debt" in the IT sense of the word. - If the contractor finds asbestos *which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"... - If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future... - If the lawyer who was origi…

I must not understand technical debt...all of the scenarios you're mentioning seem like they could easily map to a technical debt scenario

- a developer takes a certain strategy that is no longer valid (even technical debt that isn't recognized early on as being something that will have to be changed more than likely soon, is still technical debt in my mind -- your ability to recognize technical debt early on just means you know you're incurring it)

- developers often incur technical debt without explaining to stakeholders about it because a) they don't care b) they don't think the stakeholders care c) they want to get the work done and not get dinged

- developers who have to pay for technical debt may be the creators of that debt to begin with...(of course, I'd wager that most technical debt is handled by someone else who comes later because I'm rarely given the chance to fix problems I created, project managers can be judgmental like that - and project managers have to be convinced that we can just apply some more duct tape)

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

#120

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…

Controversial because it's disconnected from reality. You're putting ALL the responsibility on devs as if they are free to present any estimate they like that will then be then accepted without questions or negotation by management. In this fantasy land management is presumably operating in a vacuum with no pressure from customer deadlines, costs, investors, long term product roadmaps etc. I don't know about you but…

Sorry to tell you this, but it sounds like you have a bad manager. Your story is like not how healthy teams operate, which in my experience actually are much more like the post you're replying to.
Post reply on HN