Escape the Groundhog Day of Testing (part 2)
The Drunkards Walk
I include this analogy in these articles because even if you’re pursuing an agile process to the hilt, if you’re not learning enough in a feedback loop, you end up with what I call the “Drunkard’s walk”
If you’ve ever experienced “The Beer Scooter” after a night of revelry, you’ll understand what I mean:
“The mysterious mode of transport that gets you home after an absolute bender of an evening even though you have no idea how it was done.” ArrsePedia
Somehow after many drinkies, you managed to get yourself home magically. Obviously, the magical scooter took you home!
In reality, you did the drunkards walk.
This is where you are (in your mind) going in a straight line along the pavement. In reality, you weave your way from side to side — zig zagging along the pavement randomly, walking an extra 3 miles and taking 5 hours to get home.
OK, you’re doing nice little sprints and feints as you weave to your destination but it’s not very funny to watch.
“I am not here concerned with intent, but with scientific standards, especially the ability to tell the difference between a fact, an opinion, a hypothesis, and a hole in the ground.”
Serge Lang
You are travelling with velocity but certainly not optimally. Your little zigs and zags, particularly when you lean into them, can be very fast and agile — but you’re not getting closer to your destination, despite what your brain tells you.
The wastage that this causes in both agile and waterfall PM styles is a huge cloud over the entire web — I shudder to think of how many people write useless code for features nobody wanted nor will ever measure, just to keep a colleague happy. All that wasted development effort.
The other thing this builds is product ‘cruft’ — the way we’re all adding features and stuff to a product, but not actually removing stuff that people don’t need, use or contribute to product success. If us web folks were in retail, we’d be taking the John Lewis window display in Oxford street each week and simply stuffing more things in there, rather than taking last weeks’ display out first!
The hypothesis is a brilliant tool but not a dogmatic answer to your problems. It’s a valuable servant but a bad master if improperly handled. Please don’t assume using lean or agile methods or having a high volume of testing or activity will guarantee learning or yield from your testing programme.
Being Agile” or “Building an MVP” or “Lightweight Lean UX methods” are attributes that all sound very cool but they don’t make up for having crappy inputs to your Hypotheses. If you put a Garbage Hypothesis in, you’ll get Garbage Results out the other end. You will walk the wasteful, inefficient, drunken way to your destination. You might not even get there.
“There are two possible outcomes: if the result confirms the hypothesis, then you’ve made a measurement. If the result is contrary to the hypothesis, then you’ve made a discovery.”
Enrico Fermi
In my world, the hypothesis is what elevates simple guessing to the key driver of change within a data driven design framework.
Where UX and data meet, fall in love and get happily married. Where the inputs, knowledge and smarts of your team meet the Rumsfeldian space of the unknown unknowns.
