The thing that gets you most value for the least investment. Why stretch to reach those apples way up there when there's one right here within arm's reach?
Beware the people who use the phrase Low Hanging Fruit in a way that makes it an Alarm Bell Phrase. They will promise gobs of value for little investment, but in the end they either Nickel And Dime you, or Bait And Switch.
Proper collection of Low Hanging Fruit depends on proper profiling and optimization. Identify your bottlenecks and concentrate your efforts on them. That will give you the most value for the least investment.
Low Hanging Fruit is most vulnerable to attack by deer and other predators.
I'd think it a fine target for sheep. Predators tend to enjoy a hunt.
Quote: "Proper collection of Low Hanging Fruit depends on proper profiling and optimization."
I disagree. Low Hanging Fruit may be nothing more than the easiest part of the system to deal with at the time. No tests? Fine, test what's easiest to test with the least effort -- 'least' of course implies a relation to something else. It may take me 20 hours to test and refactor one subsystem, but if the effort to test and refactor another portion of the system is estimated at 100 hours 20 hours is suddenly not that bad. The exception to that would be that the 20 hours gains me 10 units of improved code whereas 100 hours gains me 70 units of improved code. I may then desire more to choose the 100 hours. But, it all depends on the situation. Conclusion: Low Hanging Fruit is not entirely dependent on "proper profiling and optimization."
Dead code removal is often one of the best areas of low-hanging fruit. There's a startling amount of it in most projects.
One day I refactored a couple of class hierarchies and deleted over 40 unneeded, copied-and-pasted classes. It only took an hour or so. Then I spent another hour, trying to refactor 2 more classes. I got stuck and ended up backing out of those 2, and came to appreciate the value of the Low Hanging Fruit heuristic.
This seemingly unimportant strategy (Low Hanging Fruit, which seems to be a particularization of do Easy Things First) has a seemingly unrelated example from the algorithmic arena. Quick Sort performs much faster when the shorter half is sorted first. This is counterintuitive, but think the other way around: If you sort the largest half first, then the recursion will be deeper. Non sense, you may think, since once the shorter half is sorted, the longer half will take equally as much. Well, not quite, because when you sort the second one you will use the same algorithm and therefore sort first the shortest half of the longest half and so on, therefore the deepest recursion will never occur. -- Guillermo Schwarz
See original on c2.com 