Performance Matters
So, interesting and all, but it ignores the main reason for the advice to build it first, then optimize for performance, which is that if you build everything for performance from the beginning, you end up with a lot of code that is optimizing for performance of something that isn't the bottleneck.  In other words, performance that doesn't show up in the user's experience, because something else is the main delay.<p>Now, if all that meant was that the programmer has to do some more work, and you aren't worried about paying more for the software, this may not matter, but that is far from the only (or even most important) result of optimizing everything for performance.  Instead, what you get is code that is much longer, and more complex, and therefore harder to update, and more likely to be buggy.<p>For example, one common thing you have to do to get performance, is to cache values in multiple places, instead of looking them up every time.  This can result in big improvements to software performance if done in the places which are the current limiting step, but now you have to make sure you invalidate the cache correctly.  In particular, if you don't, you get stale values in the cache, which is to say false data.<p>If you make a system with cacheing all over the place, it will be very hard to make changes correctly, which means sometimes they will get made incorrectly.  In mission-critical systems, this is even less acceptable than elsewhere.<p>It's not just "I don't feel like optimizing".  More often, it's the cost of optimizing is not worth the benefit, for this particular part of the code.  How do you know what spots in the code it's worth it?  You don't optimize, at first, and then see which two or three spots in the system are rate-limiting.