Low Hanging Fruit
Low Hanging FruitThe 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 LowHangingFruit in a way that makes it an AlarmBellPhrase. They will promise gobs of value for little investment, but in the end they either NickelAndDime you, or BaitAndSwitch.
Proper collection of LowHangingFruit 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.
LowHangingFruit is most vulnerable to attack by deer and other predators.
Quote: "Proper collection of LowHangingFruit depends on proper profiling and optimization."
I disagree. LowHangingFruit 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: LowHangingFruit 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 LowHangingFruit heuristic.
This seemingly unimportant strategy (LowHangingFruit, which seems to be a particularization of do EasyThingsFirst) has a seemingly unrelated example from the algorithmic arena. QuickSort 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. -- GuillermoSchwarz
EditText of this page
(last edited November 28, 2014)
or FindPage with title or text search