There's probably 1,000 different angles to cover here, but in general I would say it depends on the scope of the development.  Doing a minor CRM extension?  Probably doesn't make sense to burn cycles on an elegant service oriented or component architecture; just crank out some code, get it in front of the users, and refactor based on the feedback you get from UAT.  Building a large commercial app?  Then yeah, design it for performance, reusability, context abstraction, etc. Running unnecessary queries is going to add performance cost to your code, as is loading page content or JS libraries that you're not going to end up using, etc.  On the other hand, if you can create enough abstraction and build a loosely coupled component framework, you give yourself a great deal of leverage in rapidly implementing new functionality as you don't have to reinvent the wheel for basic interfaces and actions.  One basic principle that I try to follow as much as possible is read once, use many - i.e. rather than trying to perform specific functions by executing multiple queries (expensive), abstract the query to the point where it will satisfy all of the required data read operations for the given function and perform manipulation functions (i.e. aggregation, filtering, sorting) using in-memory iteration methods...now that the 1,000-item governor limit has been lifted from sets / maps / lists, this is much more straightforward than it used to be.