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

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

#41

Post by choeger » Thu, Feb 10, 2022, 11:57 AM UTC

Maintenance also has a second aspect: Bitrot.

Because we get so much of our tools essentially for free now (languages, operating systems, browsers, mobile clients) we have to accept that we don't control the pace of their development and deprecation. So maintenance must permanently adjust to an existing, moving ecosystem.

The thing is, I have never met a manager that budgeted this fromt he get go. But I also never met a manager that did not understand the sentence: "We won't be able to ship/develop after day X because big OSS project Y deprecated our version" (think CentOS repository deletion).

It is our job to keep an eye on this and report it in the terms management understands: "We use Y for free so we have no leverage and Y stops working on day X, stopping all our activities."

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

#42

Post by GuB-42 » Thu, Feb 10, 2022, 11:58 AM UTC

andi999 wrote: post #13

I think the term 'technical debt' is not good. It creates the wrong mindset if you talk to a business person, since they probably get into the mind frame of 'financial debt'. Why not call it 'we have been cutting corners in the software architecture'; I think people will understand that analogy better.

It is essentially the same as financial debt, too much debt and you go bankrupt, but if you refuse to take some debt, you may lose opportunities.

The main difference is that technical debt is hard to quantify. Financial debt is obvious, you see the numbers, interest rates, etc... You see how much repaying your debts will save you money. Technical debt, you know it is there, but you can't easily put a number, you don't know exactly how much it will cost repaying it and how much "interest" it will save you when you address it.

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

#43

Post by penjelly » Thu, Feb 10, 2022, 11:58 AM 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…

even if you were to be "slow and careful" that doesn't garuntee you'll be on schedule, it could turn out later part of your architecture is not suitable for an area maybe due to requirements changing.

maybe you'll say, "requirements cant change!" on top of the earlier "deadlines should be reasonable!". IMHO that's fantasy, I've never worked on something where both these were true for 100% of a project

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

#44

Post by carlivar » Thu, Feb 10, 2022, 11:58 AM UTC

trwhite wrote: post #17

The metric that you use to measure technical debt is "the time it takes to build new features over time". If that line on your graph is going up, you have a problem.

Agreed, and I also think measuring "rework" helps. For a car company, rework could be recalls or warranty claims. For a software company it can be outages or incidents, especially those with major customer impact.

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

#45

Post by fendy3002 » Thu, Feb 10, 2022, 11:58 AM 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…

The problem with me is many times I'm not aware that I'm introducing a debt while developing, only until it's reused or revisited that it's clear enough. Yes, even with code review process.

So even business users need to understand that there must be "maintenance phase" even for software, to pay tech debt, updating packages, patching / improving securities, etc.

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

#46

Post by adverbly » Thu, Feb 10, 2022, 11:59 AM 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…

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

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

#47

Post by rco8786 » Thu, Feb 10, 2022, 11:59 AM UTC

trwhite wrote: post #17

The metric that you use to measure technical debt is "the time it takes to build new features over time". If that line on your graph is going up, you have a problem.

Never in the history of software has that line done anything but gone up. Software naturally gets more complex as it grows to handle new features, new edge cases, more users, more backwards compatibility, etc.

This line going up is inevitable and natural. The slope needs to be managed obviously. But the only way this line stays flat is if your company is failing.

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

#48

Post by penjelly » Thu, Feb 10, 2022, 12:00 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…

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

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

#49

Post by foxfluff » Thu, Feb 10, 2022, 12:00 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…

Yeah I can see why that is controversial.

The assumption seems to be that a single developer has agency and is aware of and solely responsible for everything that's going on in the codebase that they may or may not have written.

I've been in a situation where I joined a new company and the code base wasn't looking good but my job as a new hire wasn't to redesigh and rewrite the guts of it. My job was to implement new features, one after another, usually without enough specification to even begin to estimate how long it's going to take when everything they eventually turn out to want is accounted for. The project was already very late. I tried to spend time fixing the foundation and pointing out its problems (including complete lack of tests) but I was told to stop because the customer wasn't paying for that time. The problems I pointed out went ignored.. until they messed things up in production a couple years later.

I'm gonna say they chose rubbish against my advice, and they eventually got what they wanted. Rubbish on top of rubbish, with lots of bugs and slow development.

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

#50

Post by rusticpenn » Thu, Feb 10, 2022, 12:01 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…

Unfortunately it does not work in reality. There will be another guy who is ready to do "fast and dirty", and he will be give the responsibility and probably will lead the team in future.