4 ms·

So the analogy breaks down in this: That we say "low hanging fruit" to mean "its easy and good enough; it's okay to stop and look for something else". But a f

So the analogy breaks down in this: That we say "low hanging fruit" to mean "its easy and good enough; it's okay to stop and look for something else". But a fruit farmer would say "low hanging fruit" to mean "you better design your system to get more than just that". Given the costs of fruit farming, I think it would also be a terrible idea to come to pick the fruit from your tree twice. You better not go out till you're ready to get it all (whether that's "everything" or "all of the ripe fruit"). As for me, I don't think we need to be accurate though in our figures of speech. When someone speaks of "writing on the wall" it's no objection that someone's fate was announced verbally, or that customarily, writing on the wall has no relation to future events but serves to identify something in the vicinity of the wall. Likewise for "low hanging fruit".

hinkley 8y ago
The thing is, I have a strategy that looks a lot like tree shaking, works very well for years at a time, keeps the testers and business people very happy and makes me look like a miracle worker. You pick one of the slowest modules and you concentrate on fixing all of the performance problems in it. Even the little 2% issues that would never make it onto the schedule. Then you tell your testers to retest “everything” about that one module. You get maybe a 20-30% overall improvement that way. Next cycle you do the next module. And the next. By the time you run out of modules you’ve had 2 years of steady quarterly improvements, 2 years of performance regressions, 2 years for the usage profile of your customers to shift, and 2 years to think up or learn new ideas about performance and code quality. You start over for another cycle of 15% gains.