Hayatham has an informative posting on Performance Anti-Patterns – the first one is a gem, and so true for so many projects.

Fixing Performance at the End of the Project
Software development is often a resource-constrained problem. Rarely do project or product teams have all the work years they might want. Unfortunately, an area that often receives short shrift is measuring and evaluating performance. Far too often, project teams race to the end of the schedule developing new features and fixing bugs, and performance work is left as an afterthought. They often fail to formulate performance goals or benchmarks, and the first time the developers even consider performance is after reports of performance problems are received from their beta test sites. At this point in a project, we have often joked about getting out the “perf spray,” hoping we could quickly spray on some performance as if it were some sort of flashy paint.
This anti-pattern seems obvious, but many projects have rediscovered this the hard way. If your team doesn’t bother to model or measure software performance or waits until near the end of the project to begin, it’s unlikely to get good results except by happy accident.