>What I was trying to get at was the sloppy/careless attitude I have often seen, where the developer is using a fast PC with large hard disc & lots of memory & rather than write efficiently for a slightly less able PC suggests that the user upgrade to a similar spec PC. It's the easy option. Rather than improve the code, you improve the platform it's run on.


I think that you're right to an extent, but are ignoring an important factor. The relative price of fast hardware has dropped significantly in the last 10 years, while the costs of software development have only escalated. Most of my clients would rather pay to upgrade the RAM on a few machines than pay me to spend a week trying to eke a little more efficiency out of my program by doing things like de-objectifying or writing unintuitive code that makes the application more expensive to maintain.

I see a lot of people complain about the habits of the 'newer generation' programmer citing anecdotes about the 'old days' when efficiency was key. But the truth is, efficiency was key in the old days because you had no choice- hardware was expensive, and the word RAD wasn't even invented yet. Modern code that you consider 'sloppy' because it is slow, was probably written in 1/10th the time that it would take to write the same program in COBOL 85 or 1/100th of the time it would have taken to do it in assembler. The hardware costs now pay for themselves...

I'm not saying that software performance isn't important- on the contrary, I believe that if there are otherwise arbitrary things you can do to improve the performance of your software, you would be irresponsible for not learning about them and implementing them. But many performance improvements come at the expense of less desirable application architecture- in these cases you should carefully weigh what's more important- a bit of speed, or the maintainability of the software in question.