Correct, then performant
Rob Conery just put up an interesting post (more on that later) where he talks about my example of optimizing a page from 32 queries to 4. His conclusion to that was:
I think that's a great sample of a page that was created by a developer who clearly doesn't know their way around a tool
No, it isn't. That developer was me, and that was an explicit decision made when we started working. Up to some limit ( I think it is 50 queries per page ), you can do whatever you want for development. I don't want to waste time of performance when I am developing, because it doesn't really matter when I am developing, and later I can easily start optimizing it without touching anything else in the application.
Just to give an idea, the relevant page took about a week to build, fairly complex UI, fairly complex interactions, etc. Performance is something that I can ignore until I need to deal with it, and dealing with it is fairly simple. Total time spent optimizing this page? One & a half hours or so. The result was an order of magnitude improvement in performance.
I see this as a success of this approach, because I didn't have to think about performance at all when I built the page. The fun part? I can reduce the number of allowed queries at any time, and catch any "rouge" page and fix that easily as well. Once you did it once, it becomes very easy to understand what is going on.
That is a great example of deciding what matters and when. The first concern is to get it working, get it looking right, and then getting it working fast and performant.
And no, this is not a license to ignore performance at all (using customer.HugeOrderCollection.Count is still out), but it keep you focused on the task at hand.