[samhw]

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.

[dataduck]

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.

[samhw]

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.

[Tretio]

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.

[samhw]

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.

[Tretio]

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.

[samhw]

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.