Ugh. I hear this all the time. While it's somewhat correct during early stages, it can be very wrong soon afterwards. I left a company after an extremely short

Ugh. I hear this all the time. While it's somewhat correct during early stages, it can be very wrong soon afterwards. I left a company after an extremely short time because it turned out they spent a decade ignoring scalability. They ended up completely boxed in and had no clue how to fix it. After a decade of piling things on top of each other it's extremely difficult to fix without throwing large pieces out, but they didn't want to do that. We were expected to refactor the pancake stack while simultaneously building new data centers to the old design (because being able to deploy to more than one region isn't just about "SCALABILITY DUH" it's also about data laws, regulatory requirements etc and therefore selling to certain customers). And none of the infra code was written to scale, it was pretty much hard-coded to the original data center and required thousands of search-and-replace that weren't as simple as a 'sed' operation because of assumptions like "all regions have 3+ availability zones" or failure to consider globally unique naming. The other problem with continually and habitually silencing (perfectly valid) scaling concerns is that the people who are being condescendingly told that they're "prematurely optimising" will eventually leave. When you turn this article's advice into a Harry Potter-esque spell that somebody can shout during a design session: "Premature Optimisation!" it will get abused by people who don't like detail, or want to make some stupid deadline that they agreed to before they thought deeply enough about the problem space. How long can you retain good engineers if they're constantly battling against this? When you finally saturate some choke point and your system begins to fail in unexpected ways, or your costs are too high and you suddenly realise that scalability also means scaling down too, those people who you silenced might not be there. I was once told, while cobbling together a metrics solution spanning 8 data centers that some of the things I wanted to spend a day or two on were "premature optimisation". Until we switched it on. It was dropping 50% of metrics on the floor (useless for alerting) and we got a call from the networks team because it was saturating the links. I spend those two days on my optimisations it worked. We were extremely lucky that the breakage happened at the start, and not months later. We were lucky that it didn't just turn into a random alert for a random team in the middle of the night. We were lucky that we had a network team monitoring things adequately. We were lucky that we didn't build more things on top of the bad design that relied on it. Sometimes one man's premature optimisation is another man's due-diligence. You need to be sure that your rewarding the right behaviours.