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.