Comment by bombcar
24 days ago
This is the moral behind "premature optimization is the root of all evil" - you could say preconceived just as easily.
24 days ago
This is the moral behind "premature optimization is the root of all evil" - you could say preconceived just as easily.
> you could say preconceived just as easily
Would have saved us from all the people who reject any sort of optimization work because for them it is always "too early" since some product team wanted their new feature in production yesterday, and users waiting 5 seconds for a page load isn't considered bad enough just yet.
Premature optimization doesn't mean "We have an obvious fix sitting in front of us that will definitely improve things."
It means "We think we have something that could help performance based on a dubiously applicable idea, but we have no real workload to measure it on. But we're going to do it anyway."
So it doesn't save us from anything, it potentially delays launching and gives us the same result that product team would have given us, but more expensive.
Yes, you and me understand that quote, probably mostly because we've both read all the text around the quote too, not just the quote itself. But there is a lot of people who dogmatically follow things other's write about without first digging deeper, and it's these people I was talking about before. Lots of people seemingly run on whatever soundbites they can remember.
1 reply →
> It means "We think we have something that could help performance based on a dubiously applicable idea, but we have no real workload to measure it on. But we're going to do it anyway."
the problem is that it doesn't say that directly so people without experience take it at face value.
1 reply →
Counterpoint: data driven development often leads to optimizations like this not being made because they're not the ones who are affected, their customers are. And software market is weird this way - little barriers to entry, yet almost nothing is a commodity, so there's no competitive pressure to help here either.
Honestly looking over time I think that phrase did more bad than good.
Yes, of course you shouldn't optimize before you get your critical path stable and benchmark which parts take too much.
But many, many times it is used as excuse to delay optimisation so far that it is now hard to do because it would require to rewriting parts that "work just fine", or it is skipped because the slowness is just at tolerable level.
I have a feeling just spending 10-20% more time on a piece of code to give it a glance whether it couldn't be more optimal would pay for itself very quickly compared to bigger rewrite months after code was written.