Archive for 2016

Schrodinger’s backup

Schrodiner's backup

Hence “are you doing restores?” is a better question over “are you doing backups?”.

Baby carrots are not baby carrots

Pretty interesting and insightful article from Washington Post how baby carrots reshaped carrot industry back in 1980s: Baby carrots are not baby carrots.

Just cutting carrots into 2-inch pieces made so much difference that baby carrots are now responsible for almost 70% of all carrot sales. Not to mention more than doubled per capita consumption of carrots between 1985 and 1997.

Some notable quotes:

At first, Yurosek used a potato peeler, which didn’t quite work because the process was too laborious. But then he bought an industrial green-bean cutter. The machine cut the carrots into uniform 2-inch pieces, the standard baby carrot size that persists today.

In 1987, the year after Yurosek’s discovery, carrot consumption jumped by almost 30 percent, according to data from the USDA. By 1997, the average American was eating roughly 14 pounds of carrots per year, 117 percent more than a decade earlier. The baby carrot doubled carrot consumption.

What’s more, moving the peeling process to the factory has allowed the carrot industry to make use of the scraps that used to end up in people’s trash bins.

A toothpaste factory had a problem…

Another story for engineers to show what happens when a problem is solved by someone so distant from the real production environment. The best part is that with right incentives the solution comes naturally.

Money well spent??

A Short Story for Engineers
You don’t have to be an engineer to appreciate this story.

A toothpaste factory had a problem: Due to the way the production line was set up, sometimes empty boxes were shipped without the tube inside. People with experience in designing production lines will tell you how difficult it is to have everything happen with timings so precise that every single unit coming off of it is perfect 100% of the time. Small variations in the environment (which cannot be controlled in a cost-effective fashion) mean quality assurance checks must be smartly distributed across the production line so that customers all the way down to the supermarket won’t get frustrated and purchase another product instead.

Understanding how important that was, the CEO of the toothpaste factory gathered the top people in the company together. Since their own engineering department was already stretched too thin, 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 (request for proposal), third-parties selected, and six months (and $8 million) later a fantastic solution was delivered — on time, on budget, high quality and everyone in the project had a great time. The problem was solved by using high-tech precision scales that would sound a bell and flash lights whenever a toothpaste box would weigh less than it should. The line would stop, and someone had to walk over and yank the defective box off the line, then press another button to re-start the line.

A short time later, the CEO decided to have a look at the ROI (return on investment) of the project: amazing results! No empty boxes ever shipped out of the factory after the scales were put in place. There were very few customer complaints, and they were gaining market share. “That was some money well spent!” he said, before looking closely at the other statistics in the report.

The number of defects picked up by the scales was 0 after three weeks of production use. How could that be? It should have been picking up at least a dozen a day, so maybe there was something wrong with the report. He filed a bug against it, and after some investigation, the engineers indicated the statistics were indeed correct. The scales were NOT picking up any defects, because all boxes that got to that point in the conveyor belt were good.

Perplexed, the CEO traveled down to the factory and walked up to the part of the line where the precision scales were installed. A few feet before the scale, a $20 desk fan was blowing any empty boxes off the belt and into a bin. Puzzled, the CEO turned to one of the workers who stated, “Oh, that…One of the guys put it there ’cause he was tired of walking over every time the bell rang!”

$8 million vs $20 Hmmm! Money well spent?

Source: http://cs.txstate.edu/~br02/cs1428/ShortStoryForEngineers.htm.

A tale about overdesign or how to embed a computer into toaster

How to make Toast:
Electrical Engineering vs. Computer Science

Once upon a time, in a kingdom not far from here, a
king summoned two of his advisors for a test. He showed
them both a shiny metal box with two slots in the top, a
control knob, and a lever. “What do you think this is?”

One advisor, an engineer, answered first. “It is a
toaster,” he said. The king asked, “How would you design
an embedded computer for it?” The engineer replied, “Using
a four-bit microcontroller, I would write a simple program
that reads the darkness knob and quantizes its position to
one of 16 shades of darkness, from snow white to coal black.
The program would use that darkness level as the index to a
16-element table of initial timer values. Then it would turn
on the heating elements and start the timer with the initial
value selected from the table. At the end of the time delay,
it would turn off the heat and pop up the toast. Come back
next week, and I’ll show you a working prototype.”

The second advisor, a computer scientist, immediately
recognized the danger of such short-sighted thinking. He
said, “Toasters don’t just turn bread into toast, they are
also used to warm frozen waffles. What you see before you is
really a breakfast food cooker. As the subjects of your kingdom
become more sophisticated, they will demand more capabilities.
They will need a breakfast food cooker that can also cook
sausage, fry bacon, and make scrambled eggs. A toaster that only
makes toast will soon be obsolete. If we don’t look to the
future, we will have to completely redesign the toaster in just
a few years.”

“With this in mind, we can formulate a more intelligent
solution to the problem. First, create a class of breakfast foods.
Specialize this class into subclasses: grains, pork, and poultry.
The specialization process should be repeated with grains divided
into toast, muffins, pancakes, and waffles; pork divided into
sausage, links, and bacon; and poultry divided into scrambled
eggs, hard- boiled eggs, poached eggs, fried eggs, and various
omelet classes.”

“The ham and cheese omelet class is worth special attention
because it must inherit characteristics from the pork, dairy,
and poultry classes. Thus, we see that the problem cannot be
properly solved without multiple inheritance. At run time, the
program must create the proper object and send a message to the
object that says, ‘Cook yourself.’ The semantics of this message
depend, of course, on the kind of object, so they have a different
meaning to a piece of toast than to scrambled eggs.”

“Reviewing the process so far, we see that the analysis
phase has revealed that the primary requirement is to cook any
kind of breakfast food. In the design phase, we have discovered
some derived requirements. Specifically, we need an object-oriented
language with multiple inheritance. Of course, users don’t want
the eggs to get cold while the bacon is frying, so concurrent
processing is required, too.”

“We must not forget the user interface. The lever that
lowers the food lacks versatility, and the darkness knob is
confusing. Users won’t buy the product unless it has a
user-friendly, graphical interface. When the breakfast cooker
is plugged in, users should see a cowboy boot on the screen.
Users click on it, and the message ‘Booting UNIX v.8.3’ appears
on the screen. (UNIX 8.3 should be out by the time the product
gets to the market.) Users can pull down a menu and click on
the foods they want to cook.”

“Having made the wise decision of specifying the software
first in the design phase, all that remains is to pick an
adequate hardware platform for the implementation phase. An
Intel 80386 with 8MB of memory, a 30MB hard disk, and a VGA
monitor should be sufficient. If you select a multitasking,
object oriented language that supports multiple inheritance
and has a built-in GUI, writing the program will be a snap.
(Imagine the difficulty we would have had if we had foolishly
allowed a hardware-first design strategy to lock us into a
four-bit microcontroller!).”

The king wisely had the computer scientist beheaded, and
they all lived happily ever after.

Source: http://web.cs.wpi.edu/~gogo/humor/hum_toast.html

P.S.: no wonder microservices are getting so popular.