It can depend; if it's because of sloppy programming (such as using string concatenation a lot instead of using a string builder, for example) then it's tech debt. If it's designed like that, then it's an architectural problem. I do think any naively implemented program should be able to scale up one order of magnitude, but two orders of magnitude require a new architecture.

Came to say something similar; I see it with library choices a lot as well; poor library choices ~= sloppy programming. I've had a lot of issues in the the past with 'conventional wisdom' lib choices that result in a lot of re-work as predictable issues with those choices arise.

Sometimes, choosing to use a library in the first place may also implicitly increase technical debt (in having to maintain this dependency, and even more so if this library shares dependencies with other dependencies that you have).

Sort of. You could have used better techniques/frameworks/whatever and gotten it right from the get-go. It does help to have the experience to intuit/know what you'll have to make scale and to what degree so that you can spend cycles on avoiding likely pitfalls without wasting too much effort.

I would be a very rich person if I got a dollar for every time the "right framework/solution/technique" broke unexpectedly when pushing it in certain ways.

Or it might not even have existed (or was unstable) when you started work, but it got better later.

I was thinking of things like: thread-per-client vs C10K. Just go C10K all the way. That means write services to be async, async, async. Just do it. It will not be the case that thread-per-client is better than C10K except when you know you'll only have a handful of clients. Write code to be thread-safe / reentrant. Write code to be separable into libraries.

I'd also urge you to use higher-level languages from the get-go. If you can use Rust instead of C, do it. If Haskell is appropriate, use it. These are all choices that are fantastically easier to make early on than later.

Yes. Some things are just obvious easy wins. And still I am surprised how often we choose to do differenT.

Its the same readon why I almost always immediately use vue or react. Because it doesnt cost me much (~0) but if that thing has to scale i’ll be ready

I think that's the point. You choose the best tech at the moment given the requirements with some headroom. Why waste engineering time to make sure it is hardened to support 10x load? Sometimes it is easy (use a different library) but most of the time it is hard.

"10x" is large or small depending on the plausible variance you can expect. A free casual game? 10x spike is quite expected. a $1000/month B2B Saas? 10x comes with a lot of predictable lead time.

Some changes can be extraordinarily difficult, so if you can foresee that you'll need, say, to make some code into a library, or thread-safe, or async, then it's best to make it that way from the get-go.

Obviously there's a bit of YAGNI in tension here.

But if you have the experience to write it correctly from the get-go at low additional cost, then it's worth doing that instead of risking a massive rewrite later.

> to make some code into a library

I have never had any problem with putting some code into a library after the software is done. It is almost always a 1-4 hours exercise, and when it's not, it's a 2 days task at most.

Async code is also something that I have never seen it being a huge problem. Mostly because only a small part of your code needs to be async, most of it can stay synchronous, scheduled by the small async part.

Thread safety is a real problem. One can indeed trade some of it for some development speed, and this can become a huge bottleneck later/soon.

Technical debt is the cost of reworking software not the features or existence of the software.