Live data from Hacker News

We sound like idiots when we talk about technical debt

cyclic.sh

141–150 of 198 posts

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

#141

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…

> Bob says it would take 2

Tell Bob I wish him the best of luck in this endeavor, he's clearly a better programmer than I am.

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

#142

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

If dealing with technical debt has a toll on one’s mental health then maybe they should transition to a different profession. Dealing with technical debt is part of your job description. Most people don’t have the luxury of ignoring the hard parts of their job.

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

#143
post #47
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.

Most software has short periods when it goes down. And then go up again.

I think the correct framing is that it should go up only with the logarithm of the code's age or size. If it's going any faster, you have a problem.

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

#144
post #77

Earlier quoted context omitted.

Well if you delete the codebase you no longer have any tech debt, problem is technically solved. Big brain time.

Exactly. So obviously the code base is an asset. If one then want to define technical debt it is more like the difference of the value of the code base compared to the imagined/perceived value of the code base. But this does not help with anything as well, since you could also just adjust the perceived value of the code base to reduce technical debt.

> compared to the imagined/perceived value

I guess the word you are looking for is "necessary".

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

#145
post #77

Earlier quoted context omitted.

Well if you delete the codebase you no longer have any tech debt, problem is technically solved. Big brain time.

Exactly. So obviously the code base is an asset. If one then want to define technical debt it is more like the difference of the value of the code base compared to the imagined/perceived value of the code base. But this does not help with anything as well, since you could also just adjust the perceived value of the code base to reduce technical debt.

You cannot reduce the perceived value of the codebase in most cases since the value is already communicated with the customer, there might even be contracts, and SLAs.

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

#146
post #131
post #122

Earlier quoted context omitted.

I don't understand your point here. In literally all these scenarios, you would still be billed, and it would be appropriate.

My point is: technical debt from the point of view of Business is something that the developers themselves introduced or did not manage properly, so trying to make it look like something beyond their control ("we just found out that in the 70s someone put asbestos under the roof") will sound a bit unconvincing.

Totally on point, but if I may offer a twist:

Say you run a large plumbing company, and you discover your plumbers took shortcuts on a particular job that resulted in an abundance of leaks for a given project.

The plumbing company cannot ask the plumbers for their pay back. They will have to eat the cost and fix the plumbing.

So, it's the business's problem either way. They can additionally choose to fire those plumbers if they want, which is line with your point of not believing the plumbers had no idea.

But it's still the company's debt to pay. They made the mistake of hiring people that were not capable of surfacing risks.

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

#147
Hah :) I've also had a recent blog-post length thought about this entitled:

"Technical Debt is really Software Debt. And it’s a AAA-rated CDO." https://www.evalapply.org/posts/software-debt

Context:

> I’ve long struggled with the Technical Debt metaphor. It was immediately useful when I first heard it. I still think it is useful, albeit as a starting point. The more I worked with software, the more infuriatingly incomplete it started to feel.

> One source of my unease is that I think discussions of Technical Debt don’t sufficiently examine the nature of the Risk of the underlying challenge. The other is that the concept skews and pigeonholes the Responsibility part of the underlying challenge.

(More at the post. And if I sound like an idiot in there, may I be an AAA-rated one. :)

Edit: add some context from the blog post.

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

#148

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…

> Technical debt is something that 'business users' don't need to or want to care about. Sometimes it's hard to tell your manager: Yes I know you want to track every single coding task in Jira, and you don't see any immediate value to this one, and I'm not going to dispute that, but I am going to do it and you "don't need to or want to care about it". Sucks not to have that autonomy but it's real. That's when you hav…

It's also important that they know, so no one is surprised when the next release goes out with those changes and it turns out that an edge case wasn't tested. You don't want to have to explain that something broke because you made a decision on your own to clean up the code.

When you're getting permission to do something like that, management is deciding if the risk/reward tradeoff is worth it, and I think it's only fair to give them the opportunity to make that analysis.

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

#149
post #131

Earlier quoted context omitted.

My point is: technical debt from the point of view of Business is something that the developers themselves introduced or did not manage properly, so trying to make it look like something beyond their control ("we just found out that in the 70s someone put asbestos under the roof") will sound a bit unconvincing.

Totally on point, but if I may offer a twist: Say you run a large plumbing company, and you discover your plumbers took shortcuts on a particular job that resulted in an abundance of leaks for a given project. The plumbing company cannot ask the plumbers for their pay back. They will have to eat the cost and fix the plumbing. So, it's the business's problem either way. They can additionally choose to fire those plumb…

"They made the mistake of hiring people that were not capable of surfacing risks."

Exactly the problem we always deal with: Business tends to distrust Tech because we always seem unable to stay on top of things we build ourselves

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

#150

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 Agile process that companies insist on using includes technical debt as part of the deal. It's impossible to write software with constantly changing requirements, that you have no idea about more than 2 weeks ahead, and not incur technical debt. I would guess that nearly all technical debt is due to this, and not due to developers rushing.
Post reply on HN