I'm a pragmatic, "put it in the done basket now" kind of guy, and have argued the author's viewpoint to people over engineering things countless times. General

I'm a pragmatic, "put it in the done basket now" kind of guy, and have argued the author's viewpoint to people over engineering things countless times. Generally I argue against the optimization route when I feel like we're facing a choice of delivering something not optimized that pleases customers, vs having something really technically cool that's only partially finished and not delivered. A lot of developers tend to fill all available space and time with useless engineering for some kind of street cred. But there is another side of this that the author is not mentioning. For a lot of applications, if it's not going to scale properly, then the great success the company seeks becomes its most dangerous risk. This is because you often can't control the adoption rate of your application. For many kinds of applications, once the load gets to that critical tipping point, the entire system goes into an unstoppable death spiral of doom. The whole thing won't run. For God knows how long until you do who knows what to make it go again. And what happens to your business during that time? For some kinds of businesses, that downtime isn't too big of a deal. But for others, it could be enough to make the customers regret they ever signed up with you. Still, premature optimization is evil, I can't deny it. I think the best solution to the quandary is to have and create tools and skills within the team such that building apps that can scale without too much danger isn't much harder than building plain apps.