Are you developing foolproof solutions?

37

developing foolproof solutionsAs oil and water, hardware and software don't mix, but rather work hand-in-hand together to deliver value to us, their creators. But sometimes, we make mistakes, behave erratically, or deal with others who might make mistakes, behave erratically, or even take advantage of our technologies.

Therefore, it is imperative for developers, whether hardware or software engineers, to foresee unintended (probable or improbable) system usages and implement features that will make their creations foolproof, that is protected from misuse.

In this post I won’t lecture you about various techniques of developing foolproof solutions, nor will I present even a single snippet of code. Its purpose is to stimulate your multidimensional view of problems, to unleash your creativity and to empower you to become better at solving problems, whether you develop or test software or hardware, market or sell it, write about it, or just use it.

You May Also Like: Are you solving the wrong problem?

The anecdote I’m about to tell you originated in Russia, but since there was no way to translate this fictitious story exactly without losing its meaning, I attempted to preserve its essence while adapting it to the “English ear” with some help from Sir Arthur Conan Doyle. Well, sort of. Here goes.

The Art of Deduction

Mr. Sherlock Holmes and Dr. Watson were traveling in an automobile in northern Russia. After many miles alone on the road, they saw a truck behind them. Soon enough, the truck pulled ahead, and after making some coughing noises, suddenly stopped right in front of them. Sherlock Holmes stopped their car as well.

Dr. Watson: What happened? Has it broken?

Holmes: I don’t think so. Obviously, it ran out of gas.

The truck driver got out of his cabin, grabbed a bucket hanging under the back of the truck and ran towards a ditch on the road shoulder. He filled the bucket with standing water from the ditch and ran back to his truck. Then, without hesitation, he carefully poured the bucketful of water into the gas tank. Obviously in full confidence of what he’s doing, he returned to the truck, started the engine, and drove away.

Dr. Watson (in astonishment): What just happened? Are Russian ditches filled with gasoline?

Holmes: Relax, dear Watson, it was ordinary ditch water. But I wouldn’t suggest drinking it.

Dr. Watson (still in disbelief): What, do their truck engines work on water, then?

Holmes: Of course not, it’s a regular Diesel engine.

Dr. Watson: Then how is that possible? If the truck was out of gas, how was it able to start back up after water was added to the tank?!

Who knew Sherlock Holmes had such engineering acumen!

Holmes: “Elementary, my dear Watson. The fuel intake pipe is raised a couple inches above the bottom of the gas tank. That produces the effect of seemingly running out of gas when the fuel falls below the pipe, even though there is still some gas left in the tank. Remember, oil and water don't mix.  When the truck driver poured a bucketful of water into the gas tank, that water – having a higher density than the Diesel fuel – settled in the bottom, pushing the fuel above the intake opening thus making it possible to pump it to the engine.”

After a long pause – longer than it usually takes to come to grips with reality – Dr. Watson whispered in bewilderment.

Dr. Watson: Я не понимаю, I don’t understand!

Then, still shaken, he asked the only logical question a normal person could possibly ask under the circumstances.

Dr. Watson: Why would they raise the fuel intake pipe from the tank bottom in the first place?

Holmes: Ah, Watson, it must be to make it foolproof. What if some fool decides to pour a bucket of water in the gas tank!

 

You May Also Like: Are you solving the wrong problem?
Share

About Author

Leonid Batkhan

Leonid Batkhan, Ph.D. in Computer Science and Automatic Control Systems, has been a SAS user for more than 25 years. He came to work for SAS in 1995 and is currently a Senior Consultant with the SAS Federal Data Management and Business Intelligence Practice. During his career, Leonid has successfully implemented dozens of SAS applications and projects in various industries. All posts by Leonid Batkhan >>>

37 Comments

  1. Jaime D'Agord on

    Problem-solving at its finest. This was a great read!

    This article really stimulates the brain.

  2. Tom Gaughan on

    Leonid, I found it a very fun way to get an essential point across. Plus, having read all the Holmes stories (albeit years ago), I appreciate the leverage of these characters in the effort.

    • Leonid Batkhan

      Thank you, Tom. It is flattering to receive a stamp of approval from you who have read all the Holmes stories in their original language - unattainable luxury of my time.

  3. Great story Leonid!

    Occasionally someone other than the software developer responsible for a particular persisted data structure will surreptitiously dump the containing physical file and ask questions like this: “Why does it seem they’re always 40 bytes of binary zeros at this offset? Isn’t this space being wasted?“. In the next release only 32 bytes of binary zeros appear on the next int64 boundary past the original offset. Then finally, after several more releases only 16 bytes similarly remain.

    Based on your excellent (not to mention very clever) Blog post, I’ll leave the answers to my questions as an exercise to the reader.

  4. Leonid, this is a pretty spot on anecdote! And this thinking doesn't come easily but the more you learn to recognize it the better prepared you are to tackle your problem. Good one!

  5. Thank you Leonid, your story was funny and illustrative. Sometimes a good joke has more educational value than hours of droning.
    My favorite story of this sorts is:
    Holmes and Watson went camping. In the middle of the night Holmes woke up Watson and asked
    - Watson, could you look above and tell me what do you think about it?
    - Well Holmes, the stars are shining bright, tomorrow is going to be a beautiful day!
    - No Watson, it means someone had stolen our tent!

  6. And my favorite story about flammable liquids:

    At some factory there was a tank with high proof spirits for the technical needs. The tank was filled each morning to the mark and flushed empty at the end of the day. During the day, an angry lady sat beside the tank and allowed only the ones with proper paperwork to touch it. A question: how did the creative folks from the factory take their share for the recreative consumption?

    Elementary, they put a bucket inside the tank. When the tank was flushed and the angry lady went home, they pulled the full bucket out.

    • Leonid Batkhan

      It is well known that craving stimulates creativity. Question: why would they flush the tank with alcohol at the end of each day if there was such a high demand for it? It's not thrifty. 🙂

  7. Really Nice. There is real need to design fullproof solutions, you can't even imagine , how your solution can be exploited.

  8. Thanks Leonid, it was indeed an interesting and thought provoking story. My take from the story would be to do a density (QC) check at every self start (intake of input), and accept/reject the fuel based on QC standards set. Let any fool add any fuel (input) into tank (application/system). And definitely QC standard should be questionable. Keeping fuel pipe raised is definitely not a foolprof solution.

    But, on the other hand, actually, nothing is fool proof. Leaving truck at mercy of driver is risky, but definetly a continuous source of feedback.

    Apart from that, how good your system is will depend on what it does once a bad fuel (input data) is injected into the engine. Will it keep on misfiring? Is it intelligent enough to adjust it's RPM with this bad fuel? Will it blast off immediately? ... Bla bla ... Infinite possibilities, with infinite solutions. Developing foolproof software is a bliss 🙂

    • Leonid Batkhan

      Thank you, Ritesh, for your feedback. Obviously, it's not possible to develop 100% foolproof solutions, but keeping this aspect of design in mind is a good thing as it allows avoiding obvious design deficiencies. (That is why I chose rear view mirror as a featured image for this blog post. When driving, it is imperative to look forward, but it’s also worthwhile to glance back from time to time.)

Leave A Reply

Back to Top