If you're worried about being able to handle a volume of 10,000 on the first day, then the answer is probably "NO".
OTOH, if you're concerned about designing something industrial strength from the inside out, then the answer is probably "YES".
YES, you might as well build reuseable components now if you know you'll need them. If you know what you're doing, that shouldn't take any longer that writing the same code multiple times.
YES, you should write processor intensive code at a low level if you know you'll only have to rewrite it later. Again, doing it right in the first place shouldn't take any longer.
YES, you should build a flexible enough architecture if your specs and design aren't yet frozen in stone (whose are?)
YES, you should probably be doing lots of things right now to avoid doing them twice. You must use your professional judgement about which ones.
A blanket NO bypasses that judgement. That's not being fair to yourself.
I agree that the answer is not exactly "No", but I disagree with most of your points.
Building reusable components, coding at a low level and building a flexible architecture all take considerably more effort than their alternatives, IMHO.
That being said, it makes sense to have the big picture in mind for the first time around and to take some small considerations on the way.
Avoid doing inherently bad things like schlepping around tons of unneeded data and not doing some simple caching.
Like the recent post about embracing technological debt, much of the early work may be discarded before it see the light of day so no point in over investing.
Rather that doing lots of things right the first time, I spend more effort not tightly coupling the pieces so that when you have to write something twice (and you will), it's a clean separation. I'd get the processor intensive stuff done with as little effort as possible (and likely barely fast enough), but in a way that I could rip that part out and plug in some native code when the time came.
My favorite examplei is naked SQL vs an ORM. The ORM will never be able to write queries that perform as well as if you write them all by hand. But, you'll be able to crank out functionality much faster.
Eventually, if you're lucky, you'll have enough traffic to warrant going back and rewriting some of the ORM calls using a SQL query optimized by hand.
Lastly, 99% of the time, the query you end up optimizing will not be the one you expected to when you started writing the app. That's because between when you started and now, the direction has changed significantly and you finally know what it is that you're really building.
No, arguing about semantics does not mean what you think it does! It means arguing about what words mean instead of arguing substantively about the meanings themselves.
There are 2 kinds of scaling.
If you're worried about being able to handle a volume of 10,000 on the first day, then the answer is probably "NO".
OTOH, if you're concerned about designing something industrial strength from the inside out, then the answer is probably "YES".
YES, you might as well build reuseable components now if you know you'll need them. If you know what you're doing, that shouldn't take any longer that writing the same code multiple times.
YES, you should write processor intensive code at a low level if you know you'll only have to rewrite it later. Again, doing it right in the first place shouldn't take any longer.
YES, you should build a flexible enough architecture if your specs and design aren't yet frozen in stone (whose are?)
YES, you should probably be doing lots of things right now to avoid doing them twice. You must use your professional judgement about which ones.
A blanket NO bypasses that judgement. That's not being fair to yourself.