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

61–70 of 198 posts

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

#61

Post by SideburnsOfDoom »

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…

> 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 have to justify the refactor, and not with potentially offensive statements like above.

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

#62

Post by magicalhippo »

rusticpenn wrote: post #50
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.

Guess it depends on your management.

I've often told my boss the feature would be easy, but I would also like to take the time to clean up the code in the affected area since it's making it harder than it should be to implement changes. And I've gotten some time extra to do just that.

Other times I say doing it fast and cheap is possible, but I see an opportunity here to do something more clever and involved which will very likely open up further possibilities down the line. For example, I might predict other clients will need a similar feature, so by making my code a bit more general it should be easier to implement if they come asking for their variant.

Sometimes I get a green light on that, sometimes I do not.

I guess it helps that the owners are playing the long game, so my boss can afford to see beyond the next quarter.

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

#63

Post by andi999 »

stubish wrote: post #57
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.

I like the term because it is like financial debt, and is a good way of communicating the problem to a business person. The debt will need to be paid off at some point, the longer you leave it the more that is going to cost, and it costs you even if you just keep paying the interest. Framed this way, it also helps us explain why many business people don't care . Many will only care about the projects they are current…

Well, if too many corners are cut, people understand it as well 'for this feature we have to fix the architecture, we have been cutting too many corners, so otherwise the whole thing will crumble' makes it pretty clear. Also it term makes it clear why the state is as it is (since cutting corners also 'solves' problems). How do you explain why engineers would have been allowed to take on debt on the company?

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

#64

Post by ljm »

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 think the concept here is similar to the behaviour a lot of people exhibit when trying to say 'no' to something. Generally the 'no' is non-negotiable, but a layer of reasoning is added on top that invites the other person to negotiate.

Person A: "Sorry, I can't do this because of X, Y and Z."

Person B: "Well, can't you do X, Y and Z another time instead? This is important."

You never really wanted X, Y and Z to be part of the conversation, but now they're in it and you've been placed on the defensive. If X, Y and Z were never mentioned in the first place, they wouldn't be on the table and you wouldn't have to justify them.

Same as it is with stuff like tech debt and non-functional requirements. You want to do them, you most likely have to do them, so bake them in. Keep the tech debt and NFRs off the table but leave the features open to negotiation.

Obviously has to be within reason if you want to maintain credibility, so you've got to figure out how to prioritise your tech debt too. And sometimes that means you don't do any of this and you accept a bit of interest on that debt.

Tradeoffs all the way down.

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

#65

Post by OJFord »

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.

That would work really well if it were possible & straightforward to consistently estimate complexity story points, independently of time. Even better if you could (ditch Fibonacci, necessarily, and) objectively match each complexity value in linear scale relative to the others.

In order that you could say 'it's now taking us twice as long per complexity point as it was last year', and know that that was meaningful.

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

#66

Post by wokwokwok »

ahtihn wrote: post #36
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…

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 long term outcomes in your project.

Part of your job, as an engineer / developer / whatever to spend a portion of your time not just doing work, but ensuring you can continue to deliver value in the future.

Here's a metaphor for you:

Some people like 'release based' branching; because you can push all your changes into develop (however messed up they are), and then some poor soul has to someone pull out a release candidate and then slave away over it to make sure it works...

You release seldom... but, most developers don't have to worry about it (just the release manager), and its fine.

Some people prefer trunk based development; it's harder.

Every merge to master you have to make sure your code actually works, because hey, it might go live in the next 2 hours.

A lot of people really hate this, because it means they have to do a lot of work and they cannot push the hard work onto someone else.

...do you see the metaphor?

I think it's pretty relevant.

Address technical debt slowly and continuously, not rarely and massively, and you will, in my opinion and experience, have better outcomes.

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

#67

Post by samhw »

Tretio wrote: post #58
samhw wrote: post #38

Earlier quoted context omitted.

Well, that seems like a wasteful amount of time to spend on prototype products or functionality. It's up to you if you want to do that, but other people will likely out-manoeuvre you by being agile enough to iterate quickly.

I did not say that I'm slow due to this or not agile. But I will not build a sync feature and not having alerting if it fails. I will not write nee Features and will not think about a proper index. If you do it right and actually learn those things from an early point those things become obvious. And yes there is also that believe that a bug in production costs 10x what it would cost to find while developing. Yes I'm…

No one is saying you have to needlessly screw things up. If you're writing things in an equally laborious but worse way, that's just being a bad programmer – nothing to do with tech debt.

Tech debt is more, say, "let's build this new bookmarking functionality by saving bookmarks locally" and then, later on, "let's make it more extensible by syncing them with the server, so we can build on it by e.g. using this information in our new recommendation algorithm".

It's about implementing things in a less complex but less extensible way, and perhaps a less feature-rich way, so as to more quickly validate user demand and thus iterate more quickly.

And yes, it's trivially true that you'll be slower than you could be otherwise by not doing this. You might think you're still faster than other people will be. I wouldn't bet my own money on that, but it's your prerogative to bet yours.

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

#68

Post by hobs »

samhw wrote: post #54
hobs wrote: post #30

People saying "its on you" and "has your boss ever reviewed the code?" have not had varied enough experiences. Ever had your boss tell you a feature needs to be delivered next week or the business closes? Or that you're fired? I have in fact had my commits gleaned by my boss, told me "no, we're not shipping these 10 lines of code because that goes too far and not what I asked" and then refused to accept the pull requ…

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 .

For sure! And most of the time I would say spending 20x the time on a thing that you have no flipping idea is going to land is worse than technical debt, its called closing your doors.

I just wanted to call out the posters who blame individual eng for the product quality, they've either never worked in a toxic org or are helping be the source!

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

#69

Post by samhw »

dataduck wrote: post #52
samhw wrote: post #24

Earlier quoted context omitted.

The point of technical debt is that you don't want to invest an amount of time appropriate for [long-term business-critical feature which will be built upon] into something which is currently [basic experimental feature which may well be ditched]. When the latter is validated and becomes the former, that's when - and why - you repay your tech debt. A team that builds everything as though it were a business-critical f…

The issue is with non-technical people who see that the hacked together mess of a proof of concept "works" and insist that you can just build straight on top of that without any work to make it into an actual working codebase.

Yeah, that's where the engineer/s need/s to be able to explain things clearly to non-technical stakeholders - which is vital for many other things besides this.

I think our hypothetical company would likely founder on any of a hundred other issues before this one if none of the engineers had this skill.

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

#70

Post by asplake »

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 or not I agree 100%. You are a steward of the system. The hard part is to define “system” broadly enough to include an outlook that is at least medium term (relative to individual features) but not so broad that you kid yourself that you should be second-guessing things beyond your competence. Somewhere in that range is a sweet spot where a healthy negotiation could go either way, depending on circumstance and opportunity.
Post reply on HN