The $8M Replacement for a $20 Dollar Fan (2013)
workforcesolutions.stlcc.edu
workforcesolutions.stlcc.edu
https://en.wikipedia.org/wiki/Alka-Seltzer#Marketing http://www.snopes.com/business/genius/alka-seltzer.asp
If it isn't literally true, and I have no idea, many many things just like it are.
Heck, I could probably collect a few dozen stories from HN folk right here about projects they've done where they've wasted tens of thousands of dollars (and up to arbitrary amounts of money) delivering something that their customer didn't want and anybody could have found that out with a single question in 10 seconds, if anybody had thought to ask OR if management had taken the answer seriously.
It's the winner of the memetic evolutionary war. No sarcasm. It doesn't mean much. I think that you're likely correct that the more complicated and nuanced versions don't survive, because they transmit less well. It's still not exactly a stretch to say that lots of money gets wasted all the time for very, very similar reasons.
Most of them leave the $20 solution in place as they can then save $$$ over paying for a 'proper' solution (someone typically comes up with the $20 solution before the $8m solution makes it to the RFQ stage).
Anytime you want to replace a simple analog solution with a complex digital solution, your costs aren't 1to1.
Also, now I can actually read the article!
https://www.scientificamerican.com/article/fact-or-fiction-n...
Which in fact did happen and is (in my opinion) a far more interesting story in this vein.
Isn't there a similar story after the challenger accident where he talks to the maintenance people on the ground?
Product people want to push products. Management wants to manage. Engineers want to engineer. Nothing about any of this is inherently bad, but putting these three motivations together in a vacuum can have this effect.
This is all, in my opinion, an example of resume driven development. Everyone wants to build themselves up. In a competitive market, you have to. For product people that means delivering products, for management people that means managing problems and finding successful solutions, for engineers that means engineering cool shit that works.
We are strongly motivated to behave this way.
The point of the parable is that these motivations don’t necessarily lead to the optimal solutions. And that the difference between the highly productized, well-managed, elegantly engineered solution and the quick fix is often not large.
But there’s a strong reaction against boring solutions. Boring solutions don’t get you the next gig. Boring solutions don’t impress anyone. Boring solutions don’t make your resume pop.
This is a grossly exaggerated example, of course, but that’s how parables work. I’m kind of surprised by how many of the comments are missing the point.
This tendency to over-engineer, over-productize, and over-manage is everywhere in the tech industry. We do it everywhere. Not to start a flame war, but I’m Looking at you, new JavaScript framework flavor of the month. I’m looking at you, infrastructure platforms and noSQL solutions.
The thing that we don’t seem to be able to accept is that the vast majority of the problems we solve day in and day out at our startup companies and our big big companies are very straightforward and boring problems, for which there already exists a boring solution.
This is more specifically true of web development than native dev work or embedded systems, and there are obvious places where this is entirely untrue. Cutting edge research in theoretical comp sci, embedded systems, AI, and cryptography.
And I say this as a web developer, not one of the other interesting things I mentioned above: most of what we do is and should be boring. They are simple interfaces to data. A very few of them—-maybe .01%—have to actually deal with scale.
I know I sound like a grumpy old man, but that’s increasingly what I feel like.
One of my most recent projects reflects this so closely that it’s not even funny. We had a project without enough time, we wanted to bring in a vendor to deliver a system-wide platform. Vendor couldn’t deliver on time, so we had to do something else.
My solution took a day to prototype and another few days to deploy. It was boring as fuck. No one would be even remotely impressed with the implementation. It was a boring problem with a boring solution. But it solved the problem, and we were free to move on to something else.
If we want parables like this to go away and stop offending us because they aren’t literally true, we (especially us web developers) need to stop pretending that we are so special. Product and Management should also do the same thing.
Most problems are boring, and they deserve boring solutions. Yeah, I know that doesn’t help your resume or mine, but you don’t get paid by a company to bump your resume. You and I get paid to solve mostly boring problems. Until we are willing to admit that to ourselves and each other, this parable is going to remain relevant.
A toothpaste factory had a problem. They sometimes shipped empty toothpaste boxes without the tube inside. This challenged their perceived quality with the buyers and distributors. Understanding how important the relationship with them was, the CEO of the company assembled his top people. They decided to hire an external engineering company to solve their empty boxes problem. The project followed the usual process: budget and project sponsor allocated, RFP, and third-parties selected. Six months (and $8 million) later they had a fantastic solution – on time, on budget, and high quality. Everyone in the project was pleased.
They solved the problem by using a high-tech precision scale that would sound a bell and flash lights whenever a toothpaste box weighed less than it should. The line would stop, someone would walk over, remove the defective box, and then press another button to re-start the line. As a result of the new package monitoring process, no empty boxes were being shipped out of the factory.
With no more customer complaints, the CEO felt the $8 million was well spent. He then reviewed the line statistics report and discovered the number of empty boxes picked up by the scale in the first week was consistent with projections, however, the next three weeks were zero! The estimated rate should have been at least a dozen boxes a day. He had the engineers check the equipment; they verified the report as accurate.
Puzzled, the CEO traveled down to the factory, viewed the part of the line where the precision scale was installed, and observed just ahead of the new $8 million dollar solution sat a $20 desk fan blowing the empty boxes off the belt and into a bin. He asked the line supervisor what that was about.
“Oh, that,” the supervisor replied, “Bert, the kid from maintenance, put it there because he was tired of walking over to restart the line every time the bell rang.”
https://doranscales.com/checkweighers/in-motion-checkweigher
Most of the time, it isn't. That's the point.
In fact the whole lesson here is about exactly this.
Maybe.. maybe not. One possible outcome:
Likely problem: speed of production. Solution: slow down production. Analysis: the loss on sometimes empty boxes is much lower than the loss on a slower production line. Conclusion: the fan is the correct solution.
Now if you can turn yourself into a summarization bot....
A summary is when you pull the relevant points out of the entire document.
Especially when the part quoted here was a quote inside the original article. The entire native text of the article was discarded.
It took $8 million to take a problem that was only visible to the sales department -- empty boxes are hurting our image! -- and make it visible to the stakeholders who had the right insight to actually fix it -- the people on the production line.
That is it cost $8 million to move the pain point to the "right" spot.