Posted On: Friday - September 1st 2017 2:50PM MST
In Topics: Economics
This post is mostly off of any topic covered before on Peak Stupidity, as honestly, I cannot yet distill out any stupidity from this idea - low-hanging fruit. This is just to give a better example in real life
As the newly-added picture in that previous post showed, the term comes from the obvious thinking that one should pick (a) that fruit shown over (b) some other fruit easy to get to, but not in that good shape OR (c) some good fruit that is way high in the tree so hard to get to, and either (b) or (c) over some almost rotten fruit way up high in the tree. It's simple and obvious but kind of a cool way to organize things in a business setting: [Easy with Big Payoff] > [Easy with Small Payoff] OR [Hard with Big Payoff] > [Hard with Small Payoff].
Here are examples in 2 fields:
Let's do software examples - in fixing bugs one should not spend an inordinate amount of time on the bugs that don't appear much or don't really cause too much trouble AND are going to take lots of time. "The factory scanners are locking up every hour or so on this routine - we can't work like this!" "That is simple - those files are being written to a place with not enough space - this'll take 10 minutes to fix." That should get done right away. Lots of trouble can be saved with not much effort. Next, we've got "Hey, this only happens once in a long while. It's weird, but we get around it by doing this ..." "Yeah, I know how I caused that bug - I didn't change that one
Let's do engineering examples - in fixing problems, it's the same thing. Don't work on the minor stuff that ALSO takes lots of engineering effort until you've finished all the rest or just run into a total redesign. "This critical part is failing right here regularly." "We already know exactly why, due to this stress concentration point, and we already have replacement parts that have been redesigned with doublers there. That's job 1! Next, we have "The flow out of this duct is about 75 % of what it should be. It's not gonna even be noticed, but it needs to be fixed eventually." "Oh we are pretty sure that is just one piece of ducting designed wrong. We just need a few hours on Pro-E, and the shop can easily make the redesign." Or, the other way around "These valves work OK, but are kind of expensive - we can save a lot of money per unit with these other ones." "Yes, but we'll need to set up some test rig first to run cycles on them to see if they will be good enough - it'll be two weeks of engineering time, money for the shop, and a few months to get the "buyers' off their asses. Lastly, we've got "The area gets quite a bit hotter than our finite-element model shows. It is well within spec though, but I don't understand it." "Yeah, but we haven't looked at that in a while - it'll take a week for someone to get up to speed and get near figuring this out." Yes, you may want to find out in the long run, because, unlike software, there are physical principals involved, and engineers hate it when things don't work out as they should. The difference, once determined, could help us understand our next similar design better.
Wait, WHERE'S THE STUPIDITY?. (I'm not about to get a new URL at this late stage.)
Don't fret, reader(s), we're just about swimming in it.
Comments: