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

121–130 of 198 posts

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

#121

Post by trunnell »

A "culture of approvals" is one root cause of this situation. Something needs to be done, but instead of doing it an engineer asks someone else for approval and doesn't receive it. Healthy teams don't work that way.

In a healthy team, engineers are responsible for the health of the system.

In a healthy team, engineers make decisions about non-product-feature related work, including tech debt. Product managers decide the relative priority of product changes. Engineering managers (who must be just as technical as the engineers on their team) make schedule decisions, balancing the health of the code base and the product needs.

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

#122

Post by xionon »

Pamar wrote: post #112
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…

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 don't understand your point here. In literally all these scenarios, you would still be billed, and it would be appropriate.

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

#123

Post by Gareth321 »

zaptheimpaler wrote: post #84
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…

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…

In your scenario your manager appears to be your adversary and not your manager. Those comments are what I would expect from a stakeholder, but not a manager. Your manager should provide a unified front to business and senior management. You two should agree on the correct approach. If your manager doesn't believe that your team should build things correctly and minimise technical debt then he's a terrible manager and you should leave.

Your entire scenario would be moot if you practised scrum and estimated the work effort as a team. Your manager might get a vote, but that's it.

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

#124

Post by drcongo »

wokwokwok wrote: post #66
ahtihn wrote: post #36

Earlier quoted context omitted.

Sometimes you just need to deliver quickly and cutting scope isn't an option. Sure you can say that it's not possible. Then you get replaced by someone who's willing to take the necessary shortcuts. What's important is to make it clear that you're taking shortcuts and that you will need time allocated to clean it up later. That's basically what technical debt is.

Lots of people have fought with technical debt for a long time, and if it was as easy as just being like, 'oh hey, we just do it next sprint' it wouldn't be a thing. ...it's not that easy. It's not easy. I'm not saying it's easy. I'm saying: If you do the easy thing, which is always choosing to leave technical debt behind, and waiting for someone to come and tell you its ok to deal with it... you're going to have bad…

This is still making a spectacular number of assumptions about other people's work environments. The technical debt they're dealing with may not even have been theirs in the first place, it could be an external codebase. It could be a dependency that's long since abandoned and is now a security risk. It could be that the project is deployed against a really old DB and the feature requested needs that upgrading. It could be any one of an almost infinite number of things that none of your scenarios seem to be aware of.

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

#125

Post by jimbokun »

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

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

Maybe delivering this feature in 3 days to the important client vs 8 days is important enough to put off the needed refactoring from a business perspective, or maybe not. But now the business leader has enough information to understand the tradeoff and make a decision.

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

#126

Post by drewcoo »

RHSeeger wrote: post #106
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 _n…

When you get a new heating system are any of the options "fake it til you make it?"

Would you pay for any of the options known to be unstable and will have to be replaced in a year?

What about the options that require HVAC staff to carry 24 hour pagers? When's the last time you got a whoopsie email from that manufacturer because of an outage?

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

#127

Post by jimbokun »

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 had a boss once who had a Math PhD and could throw together spaghetti code to implement his ideas.

He would give me a task to do and would basically say "don't waste time making the code clean and nice" because he knew I had a software engineering background and didn't want me over engineering anything.

I would nod, implement it "the right way" anyway, and get it done in the same amount of time.

Because doing it the spaghetti code way always takes longer in the medium to long run, and often even the short run, anyway.

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

#128

Post by Tarucho »

Part of the problem is the twisted naming we are using for development related things. Tech debt, ceremonies, sprints, masters, squads, etc.

Most business persons I´ve talked to did understood when I told them that the code was a mess, and that if we didn´t work on improving that mess we would start to get into trouble because we will be basing our work on something brittle.

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

#129

Post by corry »

One of the things I struggle with in the perennial conversations about technical debt at startups is how to account for the fact that the future in not known with certainty: i.e. circumstances can change that render very good and 'worth-it' (but expensive) technical decisions obsolete in future.

My hot take (sorry) is that business people are actually more in tune with this fact because they deal with the more chaotic side of the business (clients, funding, competition, $$$ etc). So they are less willing to give developers the time to 'do it right' vs 'do it fast', since they believe that EVEN IF it's 'right' today, it probably won't be 'right' tomorrow and we'll have to rewrite/re-do/refactor to accommodate the new paradigm/circumstances.

Of course this catches up with the business since so much duct tape will inevitably slow new development; but then tech debt can be dealt with on those terms vs. "prepaying" the cost of fixing the future problem.

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

#130

Post by Jtsummers »

Techie: We are drowning in technical debt!

Business person: Oh really! What is it costing us?

Correct response:

Techie: Every new release is taking longer and longer to complete. When we don't give ourselves the time, we have more bugs that are driving away customers.

Time is money, business people understand that. Address that aspect of the issue.

Post reply on HN