>In my mind, the biggest problem is that people that "throw code" at a problem don't realize that in doing so, they may not have achieved any performance gain with the more or less in-line approach.
>
>They like to think that not only does the code execute faster, but it takes less time.
>
>Studies have shown that while those type of solutions may be marginally faster, the overall time to implement is actually about 10% slower. Further, the support and modification time is nearly 10 times what it would be if the code was written for correctness and quality.

I agree - and on a somewhat wider basis. The only true and tried ways to write fast software is to either make it fast from the outset (avoiding known pitfalls while designing), or the classical "write it any old way you know and then take out the slow parts".

My first programming boss and mentor stopped me in my tracks when I came up with a neat trick to speed up something (in, then, Cobol). He asked "how often do we run that? If it's something that should show up faster during data entry, go for it and take two days if you need; if it's a daily report, put it on your to-do list; if it's a monthly thing, don't bother unless you really got nothing else to do".

IOW, the devil is in the detail: the definition of slow. I know I'll go and refactor anything that takes too long between two user actions. I'll play around with an SQL until it performs reasonably fast. But I know I won't spend 20 hours of coding to save a dozen users 20 seconds each year. And I'll specifically stay with a solution which I know is robust and maybe not a Porsche, if the alternative is marginally (same order of magnitude) faster but riskier.

Wow... sounds almost like a pledge :). May well be - I know the result is beneficial to my nerves :).