Uh, sort of. That quote can be abused of course, but it is still correct. Actually, this article abuses it -- it's confusing performance and optimizations. If

Uh, sort of. That quote can be abused of course, but it is still correct. Actually, this article abuses it -- it's confusing performance and optimizations. If you want performance, you design for it. When you optimize you profile and modify an existing system to improve something (usually speed, but could be other things like memory or requests, or whatever else might be constrained). I think the article makes a decent point about performance, but just shouldn't confuse it with optimizations. The right time to address the performance potential of your app or system is at design time. That's when you're going to be able to reduce the overall amount of work your system needs to do its job, and design for contingencies in case this or that box or line turns into a bottleneck. Now, it is best to do high-level design of your essential components early -- you'll not only be able ensure your system has the performance potential it needs, but other things as well, e.g., to minimize the the overall amount of code you need to write, to make your system more maintainable, etc. So I agree with the general point of the article -- "performance first" but it shouldn't really get mired in confusion over optimizations. Rather than "performance first" I'd say "do high-level design early, and don't forget to design for your performance goals".