There are different levels of expected performance for software applications. The cockpit display of a commercial airplane or that software that powers high-frequency trading machines can not afford a single hiccup; hundreds of lives or millions of dollars are at stake. For an enterprise web application, however, the tradeoff between carefully tuned software and meeting development deadlines is a treated differently, usually veering towards just getting things done. If the application works, passes its test cases, and does fine when tested under load (if one is performed at all), as a certain veteran colleague once used to joke, it is time to “print it, ship it.”
However, there are real dangers to allowing performance to take a back seat to swift development. Wall Street trading machines are carefully tuned so that not a single thing can choke their clock cycles or network bandwidth, given that fractions of a second can mean immense opportunity cost. However, consumer/enterprise web applications are subject to risk like this as well, though it is not always as obvious. For instance, Cyber Monday has traditionally been a make-or-break in terms of performance for online retailers. Also, one web company was able to increase its sales by 10% by figuring out how to reduce page load times from seven seconds down to two seconds.
How do we balance development time with performance? The solution is probably not in terms of development tools. Some software purists may argue that we need to let the garbage collecting languages start getting collected themselves, but the overhead of memory management is actually exaggerated. Much of the performance of applications is bound by network latency, and most interpreters, virtual machines, and other software abstraction layers are actually optimized enough that native code does not offer enough of a speedup to justify the headaches (time is better spent coding and designing than chasing down seg faults).
The better solution is to bring in a holistic view of performance from the very start. A good design must be made with bottlenecks anticipated in advance, and management, analysts, development, and test groups should all carefully assess the risks involved in ensuring proper performance. That may be easier said than done, but a shocking number of "performance tests" occur on production machines.
