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

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

#191

Post by austhrow743 » Fri, Feb 11, 2022, 7:59 AM UTC

hermannj314 wrote: post #104

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…

Idiot maybe not but if any of those people cited some sort of debt and then I had to pull “it’ll take longer because parts/law change/asbestos” out of them rather than just coming out the gate with it then at best I’m going to be slightly confused about why they communicated it like that. At worst I’m going to think they’re trying to play me.

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

#192

Post by paulryanrogers » Fri, Feb 11, 2022, 2:26 PM UTC

falcolas wrote: post #107

louthy wrote: post #89

Earlier quoted context omitted.

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.

This is ideal. At times though there will be pushback by engineers and product teams drunk on the high of delivering fast and often.

It also requires knowing the approximate amount of debt that may be involved in any given work. Or else actual work may far exceed estimates so often they become meaningless.

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

#193

Post by falcolas » Fri, Feb 11, 2022, 3:55 PM UTC

paulryanrogers wrote: post #192

falcolas wrote: post #107

Earlier quoted context omitted.

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.

This is ideal. At times though there will be pushback by engineers and product teams drunk on the high of delivering fast and often. It also requires knowing the approximate amount of debt that may be involved in any given work. Or else actual work may far exceed estimates so often they become meaningless.

Both of these concerns are a part of maturing as a software developer. Managing expectations, leading your team, estimating - these are soft skills required by a senior or above software engineer.

Estimates, as a rule, are never terribly accurate in the first place, often because of tech debt - adding in cleanup won't make them much better or worse. To give any kind of estimate in the first place, you need to be fairly familiar with the code, which includes the crufty bits that count as tech debt.

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

#194

Post by jimbokun » Fri, Feb 11, 2022, 4:41 PM UTC

nickysielicki wrote: post #138

jimbokun wrote: post #125

> The difference between a user story taking a day or 3 days is negligible compared to its business value. Companies and their leaders care about revenue and costs. They care about customers and growth. They care about time to market. Um, taking a day vs 3 days is huge. Because the cost of each task is now 300% of what it should be. Time to market is also absolutely impacted by technical debt, for the same reasons. D…

> Describing this to company leaders in ways they understand is pretty straight forward. "If we take a week now to fix this problem, we will be able to do 3 times as much work in the same amount of time going forward." I’d argue that technical debt that can be resolved in a week is not real technical debt. And when you’re dealing with “real” technical debt, it’s hard to substitute numbers into that sentence without l…

> and in terms of product launches it’s completely ambiguous how much faster we’re going to be.” isn't nearly as easy of a sale.

Which indicates there really isn't much quantifiable value in the refactoring, and it's probably a poor use of developer time.

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

#195

Post by chrisweekly » Fri, Feb 11, 2022, 8:47 PM UTC

Tretio wrote: post #34

chrisweekly wrote: post #29

Earlier quoted context omitted.

Agreed. But what is "Mh"?

It's a written sound like hmmm humming

Ok, thanks. FWIW, I'm 47yo, a former TEFL teacher, I pay attention to language, and I've literally never encountered "Mh" before. Hmm...

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

#196

Post by zaptheimpaler » Sat, Feb 12, 2022, 3:50 AM UTC

trunnell wrote: post #120

zaptheimpaler wrote: post #84

Earlier quoted context omitted.

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.

Thank you, really. It is nice to hear someone else acknowledge it. I'm going to start looking for a better job.

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

#197

Post by taneq » Sat, Feb 12, 2022, 12:08 PM UTC

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…

The other thing is that technical debt is not always bad. It's just another stat to manage along with budgets, ROI, available engineering time, customer engagement, etc. etc.

If you have a product that's nearing end of life and you can boost its value for another year with a quick hack, then do it. If there's a system that really needs refactoring and is getting harder to extend, but still works fine as it is, then you leave it alone. If things have gotten a little curly but are still serviceable, just roll with it. You don't just trash everything, obviously, but a year from now when you retire that codebase, any extra time spent on it now will be wasted.

In your new flagship product that you have no plans to replace for the next 5+ years, you take the extra time to keep everything nice. You re-engineer whatever needs re-engineering to add that feature like it was always meant to be there. You refactor the smelly bits of the code. You push back entropy to keep it shiny because it's likely to be worth it.

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

#198

Post by cestith » Mon, Feb 14, 2022, 2:23 PM UTC

wobbly_bush wrote: post #176

cestith wrote: post #108

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

> perhaps we should call technical debt what it really is to the business: temporal debt If they startle at the mention of "tech", how are they not going to be startled with "temporal"?

Then just say "time". Honestly, if your director, CIO, and CEO don't have a decent vocabulary then perhaps explaining this issue isn't your firm's biggest problem.