Good question. What I see daily is this.

People work on good-size apps. As they work, performance problems creep in, just like bugs. The difference is - bugs are "bad" - they cry out "find me, and fix me". Performance problems just sit there and get worse. Programmers often think "Well, my code wouldn't have a performance problem. Rather, management needs to buy me a newer/bigger/faster machine."

The fact is, if developers periodically just hunt for performance problems (which is actually very easy) they could simply clean them out.

Instead, the "state of the art" is:

1. rely on aphorisms like "eschew premature optimization" and 90/10 hoo-haw.
2. talk bravely about profiling, and sometimes actually try it, often with disappointing results, as you see in all the SO questions about it.
3. fall back on good old guesswork, disguised as experience and knowledge.

But really, that's negative. To be positive, this method works nearly all the time, and it couldn't be simpler. Here's a detailed example.

Good question. What I see daily is this.

People work on good-size apps. As they work, performance problems creep in, just like bugs. The difference is - bugs are "bad" - they cry out "find me, and fix me". Performance problems just sit there and get worse. Programmers often think "Well, my code wouldn't have a performance problem. Rather, management needs to buy me a newer/bigger/faster machine."

The fact is, if developers periodically just hunt for performance problems (which is actually very easy) they could simply clean them out.

Instead, the "state of the art" is:

1. rely on aphorisms like "eschew premature optimization" and 90/10 hoo-haw.
2. talk bravely about profiling, and sometimes actually try it, often with disappointing results, as you see in all the SO questions about it.
3. fall back on good old guesswork, disguised as experience and knowledge.

But really, that's negative. To be positive, this method works nearly all the time, and it couldn't be simpler. Here's a detailed example.

Well, what I see daily is this.

People work on good-size apps. As they work, performance problems creep in, just like bugs. The difference is - bugs are "bad" - they cry out "find me, and fix me". Performance problems just sit there and get worse. Programmers often think "Well, my code wouldn't have a performance problem. Rather, management needs to buy me a newer/bigger/faster machine."

The fact is, if developers periodically just hunt for performance problems (which is actually very easy) they could simply clean them out.

Instead, the "state of the art" is:

1. rely on aphorisms like "eschew premature optimization" and 90/10 hoo-haw.
2. talk bravely about profiling, and sometimes actually try it, often with disappointing results, as you see in all the SO questions about it.
3. fall back on good old guesswork, disguised as experience and knowledge.

But really, that's negative. To be positive, this method works nearly all the time, and it couldn't be simpler. Here's a detailed example.

Good question. What I see daily is this.

People work on good-size apps. As they work, performance problems creep in, just like bugs. The difference is - bugs are "bad" - they cry out "find me, and fix me". Performance problems just sit there and get worse. Programmers often think "Well, my code wouldn't have a performance problem. Rather, management needs to buy me a newer/bigger/faster machine."

The fact is, if developers periodically just hunt for performance problems (which is actually very easy) they could simply clean them out.

Instead, the "state of the art" is:

1. rely on aphorisms like "eschew premature optimization" and 90/10 hoo-haw.
2. talk bravely about profiling, and sometimes actually try it, often with disappointing results, as you see in all the SO questions about it.
3. fall back on good old guesswork, disguised as experience and knowledge.

But really, that's negative. To be positive, this method works nearly all the time, and it couldn't be simpler. Here's a detailed example.