[samhw]

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.

[lhnz]

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.

[samhw]

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.

[samhw]

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

[EugeneOZ]

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.

[samhw]

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.

[EugeneOZ]

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.

[samhw]

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.