embedded software boot camp

Rabbit patches and embedded systems

Monday, August 29th, 2011 by Nigel Jones

You may think from the title that I’m writing about Rabbit microprocessors – but no I’m actually intending to talk about bunnies. What you ask do rabbits have to do with embedded systems? Well read on and find out…

If you have ever had a vegetable garden then you will know that they are magnets for rabbits. Furthermore, you will soon find out that it takes extraordinary efforts to keep the rabbits out, as they have a tremendous ability to circumvent all sorts of fences.  When faced with such a problem, it is sometimes advisable to build a rabbit patch. The basic idea is this – you plant your garden and put a fence around it, and then on the outside of the fence you plant a second vegetable garden that is purely for the rabbits – i.e. a rabbit patch. The rabbits feed on the rabbit patch and leave your real garden alone because they would have to exert effort to get to it – and they don’t need to as their needs are satiated by the rabbit patch.

So what has this to do with embedded systems? Well let me describe a scenario to you that is almost certainly all too familiar to anyone that has been doing this for a few years.

It’s dog and pony show time and marketing is coming to pronounce judgement on your latest creation. Now if you are fortunate, the folks in marketing are a pleasure to work with. However from time to time, you run into someone who is incapable of attending a dog and pony show without offering criticisms / complaints. (I’m talking about the sort of person who would have criticized Michelangelo’s David at its unveiling). When faced with such an individual, I have found that the answer is to build the embedded system’s equivalent of a rabbit patch. It works like this. You intentionally put into the demonstration something that obviously isn’t quite right. Come time for the dog and pony show, the complainer latches on to the ‘problem’, and proceeds to explain in detail why it is wrong. You sit there and graciously accept the pearls of wisdom dispensed to you. You can then proceed to the meat of the presentation and get some useful work done.  The meeting ends and our protagonist walks away happy – and you have managed to actually have a useful and productive meeting. Naturally the fix to the ‘problem’ is a flick of a compilation switch.

So now you know what a rabbit patch is. I encourage you to use it sparingly. I also encourage you to watch out for it being used on you! I have sat in on a couple of presentations where I’m pretty sure a rabbit patch has been deployed. Fortunately I’m also pretty sure the rabbit patch wasn’t for my benefit…

On a personal note, I’m expecting to return to my normal blogging schedule. The long awaited hardware test may actually make an appearance soon.

 

7 Responses to “Rabbit patches and embedded systems”

  1. Excellent subversive post! Not the same, though related, is the “Suicidal Demo”.

    Those marketing guys want a demo. Fair enough, you produce one and it looks really good. Of course, it’s straight-line code with no error checking and it demonstrates only a small part of the product’s eventual capability. On the basis of this wonderful demo, though, some orders are taken and, from then on, you have to patch the demo until it resembles a product, in order to ship it. Then you go on patching it. The quality is appalling, the team is demoralised and the customer gets more and more exasperated. Not good.

    The cure for this is simple. Make a wonderful demo, of course. But at the end, it absolutely must crash, with as much of a fanfare as possible. And I mean so that only a power cycle will restart it. Warn the salesman, of course; that’s only fair. The point is that the demo does its job – it demonstrates the salient points of what will become the product – but it also exposes itself for what it is. It is very hard for a salesman to short-sell such a demo.

    Just one tactic in the war against the impossible so-called deadline.

  2. Vaibhav Garg says:

    Excellent post, and pertinent to what faces us, the embedded systems engineers. By the way, this concept is somewhat related to what the Anti-Malware vendors term as setting up a honeypot.

  3. david collier says:

    > criticized Michelangelo’s David

    The head is obviously too big.

  4. Ian says:

    Long long ago when 64K of RAM was more than enough for anything and I was developing on a blue tower Intel system I came across an interesting quirk of the OS/file system that we were using. If a file was above a certain size then the modification date on the file would be changed each time that the file was read, meaning that compiling the source could make a number of the files look as if they had been edited.

    We were also blessed with a QA manager who required 10 times as long as a normal mortal to see that a test had passed. The great day came for the witnessed testing of the system when the customer would arrive and we would run through the acceptance tests with both the customer and the QA manager checking the results.

    Somehow this date oddity was pointed out to the QA manager who got terribly excited trying to investigate all the possible implications leaving us to get on and demonstrate the system to the customer without him holding us up on every test. We were able to have a very nice lunch with the customer in the time that we saved!

  5. Steve says:

    Excellent explanation! I have always called your “Rabbit Patches” a “Red Herring”:
    http://en.wikipedia.org/wiki/Red_herring

    I find a Red Herring useful not only in demos, but also in specifications and proposals when there are strong critics in the crowd.

  6. Rasmus says:

    This is also known as “duck technique”.

    Often, product managers feel that they HAVE to change something, or else they would not contribute “value”. If you present them a perfect product, this means that they will spoil it. We all remember the famous Battle Chess, right?

    The developer of this game was aware of this product manager issue. So he made everything ready, but also added a stupid animated duck flying around the queen. The sole purpose of the duck was to give the product manager something to complain about while leaving the rest untouched. The developer took care not to cover the “actual” queen animation as to be able to easily remove the duck. The presentation day came, the product manager was perfectly fine with the software, except for the duck. So it was removed since it had fulfilled its purpose.

Leave a Reply to david collier

You must be logged in to post a comment.