Blog: Heuristics Art Show, EuroSTAR 2008

Galvanized by Jerry Weinberg‘s workshop on experiential learning at AYE 2008, I led a tutorial at EuroSTAR 2008 that included an experiential exercise invented by my colleague James Bach. I call it The Heuristics Art Show.

In small groups, people contributed, discussed, and refined headlines and descriptions of some of their heuristics, mostly to do with testing, but also to do with other aspects of life and software development. It was wonderful to tap the collective wisdom and experience in the room, and I think the results were marvelous. Many thanks to all who contributed to the exercise.

The pictures are up there in high-res form. Some of them are a little blurry, but they’re all readable if you download the high-res version. One fine day I hope to transcribe them—or maybe a Kindly Contributor could do it.

This kind of exercise will happen again at future conferences, to be sure!

The Art Show approach reminds me of the Positive Deviance Initiative—a from-the-bottom-up, practice-based approach to process improvement. Wanna get better results in a hurry? Don’t bring in the massive, unreadable tomes of “maturity” models; have real people, doing real jobs, share their practices with each other.

Here’s a great example. The problem was that, in the Albert Einstein Medical Center, contaminated hospital gowns were overflowing the trash bins. When people brushed against those gowns, there was a risk of picking up the contamination and spreading it to other patients. A fellow in the patient escort department had a beautiful solution to the problem. That solution is now known as the Jasper Palmer Method.

EuroSTAR 2008 Heuristics Tutorial 1

Want to know more? Learn about upcoming Rapid Software Testing classes here.

8 responses to “Heuristics Art Show, EuroSTAR 2008”

  1. Anonymous says:

    Box Of Chocolate
    * You never know what you’ll get

    Firstthought Right
    * Don’t keep thinking too long about the possible solution.

    Sounds lika a chicken
    * Use your senses when describing a problem.

    The Genius complex
    * The ares coded by the genius are not bugfree.

    The Sexy Chick perpective
    * Look away from the interesting b(t)its once in a while.

    Take prisoners
    * Bring “difficult” people into your team

    Don’t Feel Stupid
    * If you don’t understand – chances are you are not the only one. ASK !

    Picture/Film says more then 1000 words
    * When reporting use images and videos for describing when words fail.

    It’s always the new kid
    * A new comer will always mess something up. Test it.

    Reverse it.
    * Try it doing the opposite way. Think in 180 degrees.

    Just try it !
    * Even if you are sure it would not work.

    Don’t Berate – Automate !
    * Well that is selfexplanatory.

    The Bathroom Oracle
    * Take a break for a fresh view on stuff. ( And for toilet testing @

    Defects are Gold
    * All value of testing comes from found defects. Crap reports give no value.

    No bugs no Glory
    * Bugs make you happy. Finding bugs is fun. Day without bugs is a waste.

    Follow the Rythm
    * Projects have speed and follow a steps and patterns. Do not swim against the flow.

    Hide and seek
    * Find your friends and on the way you’ll find many interesting things. Don’t forget to find your friend.

    Tell that yo your cat !
    * Would your cat or grandmother understand what your are saying ?

    Trust People, not Numbers
    * Context : decision about what to tell “Managment”. Get facts to support.

    Don’t trust Foreigners
    * CMMI levels in different countries mean differents things.

    “It is only …”
    * Really Means : “I underestimate this problem”

    Newcast action !
    * when you see a problem videotape it – and broadcast.

    Look ! Look – No Hands!
    * People ofter use fancy words to hide their incopmetence and for distraction.

    There are no problems
    * .. Only challanges.

    Google Rule
    * Your problem is already solved by someone else. If not then make sure it’s not yours anymore.

  2. Michael says:

    That WAS a kindly, albeit anonymous, contributor! Thank you very much!


  3. Anonymous says:

    You have put a great presentation there that made me thinking a lot. Also i’ve met some great people there.
    You have also mentioned a book about architectural patterns which i’ve failed to note.
    Would you mind naming that book here so i, and other people that i’ve met, could go and look for it?
    Thank you.

  4. Michael says:

    Hi, Anon (please feel free to leave your name and address)…

    First, thank you for the kind words. I too met some very interesting people and felt lucky to have interesting conversations with them.

    The name of the original patterns book is A Pattern Language: Towns, Buildings, Construction, by Christopher Alexander et. al. At one point, I remarked to Cem Kaner that Lessons Learned in Software Testing seemed to be a book very much in the same kind of spirit, which is one of the reasons that I liked it so much. Both books are collections of heuristic suggestions about their subjects, with some excellent stories to illustrate and emphasize the points.


  5. Jeroen says:

    Hello Michael,
    Thanks for the workshop you gave and time to answer questions.
    Although I’m still in the mode over thinking what you had to say. I strongly believe that heuristics can help make complex issues, problems or even understandings easy to define goals. And perhaps define the direction for decisions.

    Often I see that time is lost collecting evidence/metrics and based decisions on those figures. My opinion is that it is better to make decisions instead of thinking making them. Decisions make people move and on movements we can act. If decisions are moving in a good direction or when they are going the wrong direction doesn’t matter. It helps us to adapt. If adaptation is done in a proper context, they should help customers better.

    At least your words had some impact as they convinced me to trust the test-the-tester-test instead of trusting on certifications.

    With regards,

  6. Anna says:

    Hi Michael,

    Thanks for a great workshop. Just wanted to add a comment on the angle of gaze (i.e. how dogs catch frisbees) heuristic you mentioned during the workshop:

    I find it really fascinating that this only seems to have been discovered in the past ten years, because there’s a very similar heuristic that’s been in use in aviation for many years.

    Except with this trajectory, you’re not trying to catch a moving object, you are the moving object, and you’re trying to throw yourself at a particular reference point on the ground, to land your aircraft. But the essential heuristic is just the same – if it’s moving up in your field of view, you’re going to fall short, if it’s moving down, you’re going to overshoot. I wonder why nobody ever reversed it?

  7. Michael says:


    I also wonder why no one ever reversed it. Except maybe I don't—when you look at it, the whole history of science is filled with people saying, "Wha…? Oh. Right."

    Thanks for the kind words.


  8. Markus says:

    If you need some more explanation to the "Stickman" heuristic you can find an small image under

    In addition to what is already there you could use the legs as reminder for testing > and < as input (might find bugs in AJAX/XML)

    You couldalso give the little fella a big and a small ear as a reminder to test max an min values.

Leave a Reply

Your email address will not be published. Required fields are marked *