Comment by Tretio | Hacker News Reader

Comment by Tretio | Hacker News Reader

Stop talking to business about technical debt.

Stop creating technical debt.

No one ever asked me why in particular something took 3 days. I don't explain to someone that I wrote unit tests and no manager told me not to write tests.

Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written?

If you accept technical debt it's the development teams fault.

And yes a not that clean feature, which is easy to refactor IF you touch it again is not technical debt.

Instead lern to talk back: "oh you promised our customer that this feature will be ready tomorrow? I'm seeing a big risk in this as there are still issues we haven't figured out, you might want to manage their expectation."

"Ah sry I can't work longer today I already have a reservation"

"On the weekend? Mh I booked a hotel already"

"How long this takes? Mh let's see (1 day guess + 100% risk + backupday) at least 3 days. I can get back to you in 2 days to give you an update."

"I can prioritize your new request but I will talk to x to tell him that his task will be delayed."

"Didn't you promise customer x feature y already? Should I stop working on y to start with your new request?"

There's (at least) three causes of technical debt that aren't due to engineering negligence (but I agree in general that many sources of "technical debt" are self-inflicted):

1. Domain modeling shifts. Engineers get a sample of the business rules for the domain they're trying to model every time they build a feature, but it's an incomplete picture. And in fact sometimes the very nature of what the business is trying to accomplish changes. That can require fundamental shifts in how the problem is modeled.

2. Changes of scale. What was engineered to support 10,000 MAU will not necessarily tolerate 100M MAU. Scale can be insidious for tech debt because it's often a slower creep of a problem w/ a high cliff in the amount of effort required to solve for it.

3. Planning/communication failures. Sometimes a critical aspect of a feature is not fully understood or articulated. Or an important delivery date for a promise is overlooked. Depending on the nature of the company's business, an early stage company often doesn't have a choice but to deliver on things that weren't properly scheduled.

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 feature, which needs to be architected as safely as the control loop on a rocket, is a business which is pathologically unable to experiment and iterate.

I'm not writing prototype Software.

Everything will find its way back to you.

Bugs are very costly.

I always make sure I für understand what the problem is. This can lead to me having discussions of 2-3 h and the outcome is that we actually don't need it. Or that we reduce the scope to deliver on time.

I'm not aware of things I write which will not bite me back one way or the other if I'm doing it shitty and having development standards is not developing a rocket.

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 aware of the fallacy that a manager might praise you if you are fast and accepts bug as a common normal thing.

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.

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.

Sorry, but how old are you? Add the line “stop creating bugs” into this text to make it complete.

I'm 34 and work like this, successful for 12 years.

I have a min. Standard I achieve and will not compromise this standard to keep me sane.

I will not create things which will fall back to me in 3 month.

I develop slower but have to revisit things rarely.

And you are working alone and on the new codebases only and your code is perfect from the beginning and you are not discovering better ways with time. I got it ;)

These are the people we avoid like the plague when hiring: people who are obsessed with the intrinsic beauty of their code, rather than its business utility.

They're welcome to do that with their own code in their own time (and many people like to do that, quite understandably), but it's toxic in any sort of business environment. You need to be able to make practical judgements about how much time to invest in, say, an MVP feature with a 70% chance of being ditched.

We were talking about another topic. “Temporary dirty MVPs” are only acceptable if their code will be completely thrown away. Otherwise, “there is nothing more permanent than temporary patches” (c) forgot who.

Yeah, certainly the tech debt code should be thrown away. I think this is hard to discuss without a concrete example in mind, though. Or rather without both having the same concrete example in mind.

I get the sense that everyone here is imagining their own - very different - concrete example of tech debt, and talking entirely at cross purposes as a result.

If the foundation, base of the project is quickly created just for MVP - it should be rewritten. If just some of the small parts were created without care - then throwing them away is not a problem.

I really need to emphasise, 'tech debt' does not imply 'without care'. Just to link to the last comment where I emphasised this: https://news.ycombinator.com/item?id=30286955

This is why I say it's fruitless to discuss this without making clear what concrete examples we're imagining when we say 'tech debt'. I'm almost certain that you and I are not thinking of remotely the same thing. 'Tech debt' is very different from plain old shitty code.

To be fair, as we are aiming to become better software engineers, on every PR we make, we should be aiming to decrease our bug rate, and increase our speed, testing, robustness, performance and the overall expressiveness.

Why don't you "simply write code faster with fewer bugs" seems sarcastic or unrealistic (or Übermensch) but over time with practice we should attempt to do this. And I do see it, within the practices of the top software engineers on GitHub, who often write better quality code than I could faster than I could. It must be achievable.

I'd agree with this, but this is orthogonal to tech debt IMO. Tech debt is a trade-off of a simpler / less extensible implementation in exchange for faster product / business validation of experimental (in some sense) code. It doesn't matter how fast the individual developer is: all that matters is that, where T is some arbitrary unit of execution speed, the simple solution takes e.g. 1T and the more future-proofed solution takes 2T or 3T.

Like I said here -> https://news.ycombinator.com/item?id=30286860, I think this whole thread is proving slightly unproductive because everyone has their own definition, and concrete example, of tech debt in mind - and so we're all talking at cross purposes about different things.

I suspect that lots of the stuff people seem to implicitly be talking about is not tech debt by my definition, but rather just shoddy code. That seems to be what your comment is talking about. If you can write a better implementation in the same time (subtracting time taken to learn about either implementation technique) then it's not tech debt AFAICS.

^ I thought I should clarify: the reason I'm making the point about relative deltas in speed is that many people ITT seem to think they can leapfrog the tricky question of tech debt by just saying "well, we should all be better engineers, and then we'd write the better-of-the-two implementation more quickly".

And that's just not so. It doesn't matter how fast or quick-minded the engineer is in absolute terms. I've worked with some of the best engineers in the world, and they still took on tech debt (albeit in an intelligent and considered way), because simpler solutions are still faster in relative terms.

Tech debt will forever be a rational choice so long as there's a comparative advantage - so to speak - in taking the simpler path.

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

Reply on news.ycombinator.com