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

We sound like idiots when we talk about technical debt

cyclic.sh

Post reply on HN
Print view View original

101–110 of 198 posts

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

#101

Post by andrew_ »

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…

> Why? Because it's always good to have an excuse to work slower.

Oof. What's better is setting and going by your own pace and making sure you're projecting expectations with regard to that pace.

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

#102

Post by mavhc »

penjelly wrote: post #48
davewritescode wrote: post #35

Earlier quoted context omitted.

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…

ah the famous "give us dev estimates, but yours are too long, lets go with shorter anyway" makes people afraid to estimate high

If after the 3rd time that happens the boss doesn't notice, that's their fault.

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

#103

Post by cestith »

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…

That's when you suggest that the historical accuracy of the proposals should be weighed to determine the degree of certainty in future proposals from various sources, right?

Let's say person A gives longer estimates but is accurate within 10% more than 95% of the time. Let's say person B gives estimates half as long, but the team runs over by 75% a quarter of the time and by 150% about half the time. Whose proposals should the stakeholders choose?

If your company is making decisions based on estimates, the accuracy trend on those estimates is a far more important metric than lines of code, number of commits, story points, or nearly any other metric they're keeping.

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

#104

Post by hermannj314 »

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

Few things in the world are future proof for every conceivable externality. No one considers these professionals idiots simply because their domain has 'technical debt' too.

It us ok to have technical debt, to mention it, to bill to fix it, and to talk about it. And you only look like a fool if you try to cover it up and pretend it isn't there because 'its not the customers's problem'

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

#105

Post by samhw »

lhnz wrote: post #99
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,…

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 solution takes 2T or 3T.

Like I said here -> https://news.ycombinator.com/item?id=30286860, I think this whole thread is proving slightly unproductive because everyone has their own definition, and concrete example, of tech debt in mind - and so we're all talking at cross purposes about different things.

I suspect that lots of the stuff people seem to implicitly be talking about is not tech debt by my definition, but rather just shoddy code. That seems to be what your comment is talking about. If you can write a better implementation in the same time (subtracting time taken to learn about either implementation technique) then it's not tech debt AFAICS.

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

#106

Post by RHSeeger »

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…

I disagree pretty strongly with what you've said here. Specifically, part of my job is to make sure my customer is aware of the options and the costs of each of those options. Doing things the faster/less robust way now will have a cost later (re-implementation of some part, etc). And then I do my best to convince them of the approach that I think is best. But only telling them about the option I think is best and _not_ discussing the viable/reasonable options... is definitely not my job.

Implementing a faster solution that will have costs later isn't me choosing to do a rubbish job. It's me helping my client make the best use of the available time/money.

When I hire a company to install a new heating system, they present me with various options; better/worse hardware, single/multiple zones, brand new hot air lines vs rewrapping existing vs using existing unchanged, etc. The person from the company may have a strong opinion on what is best, but listening to them and then making the decision I think is best is expected.

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

#107

Post by falcolas »

louthy wrote: post #89
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…

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…

So build the time of fixing tech debt into your estimates. You're right, you can't avoid creating tech debt, but you can absolutely fix it while you're mucking about in that code anyways.

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

#108

Post by cestith »

Perhaps technical debt is the wrong term to use with nontechnical people, who tend to startle that they aren't even meant to understand so soon as the "tech" part comes out of someone's mouth.

If they understand financial debt on a balance sheet and they understand schedules and Gantt charts, perhaps we should call technical debt what it really is to the business: temporal debt. Explain that because we've taken shortcuts in the past, we were literally borrowing time from the future, and that time balloons with interest until we pay it back.

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

#109

Post by samhw »

foxfluff wrote: post #76
samhw wrote: 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 .

> 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. Yeah, you can pass a proof of concept to the customer and they'll ask if it can do one more thing.. and then, tweak this a little.. and add this one little thing.. before…

Yeah, and that's when the complementary skill of knowing when to repay tech debt comes into the picture. I'm not sure what else you would be suggesting: that we should all build every experimental finger-in-the-air MVP as if it were core business-critical functionality, just so we don't have to be disciplined in judging when to repay tech debt?

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

#110

Post by commandlinefan »

What's really frustrating is that technical debt leads to real problems. It's just that these problems have been so pervasive for so long that everybody just accepts them like a bad smell that you don't really notice. Technical debt is the underlying root of:

    - you said you fixed this problem but I'm still seeing it
    - you fixed this problem but you created a new one
    - we can't deploy a fix for this problem right away because we have to certify the whole monolithic mess first
    - testing this fix takes an hour to coordinate
These are problems that business owners should care about, but they've just come to accept that this is the reality of software development.
Post reply on HN