I guess it’s more that what is developed is lead by product people and those don’t know how to plan for performance issues and instead inadvertently push for more features in a shorter time.
I don't think I've ever worked on an application where performance wasn't a problem. The ability of programmers to write slow software grows faster than computing power does.
> well designed software
Ah, there's my problem. Maybe at some point I'll get a chance to work on one of those.
A lot of your article goes on to talk about development time speed up. The original article discussed performance where it is critical, like a game. You can't have compensate on performance even if it comes at the price of higher development time.
Performance is a tradeoff. Sometimes shipping a feature is more important. Sometimes cross-platform support matters more than native speed. Sometimes performance optimizations are a distraction from other, more important, work.
> I argue that if you raise the framework's performance ceiling, application developers get the headroom—which is a type of luxury—to develop their application more freely (rapidly, brute-force, carefully, carelessly, or somewhere in between). In large part, they can defer the mental burden of worrying about performance, and in some cases can defer that concern forever. Developers on slower platforms often have so thoroughly internalized the limitations of their platform that they don't even recognize the resulting pathologies: Slow platforms yield premature architectural complexity as the weapons of “high-scale” such as message queues, caches, job queues, worker clusters, and beyond are introduced at load levels that simply should not warrant the complexity.
reply