Posthumous Retrospective on Google Wave

By beaching Google Wave little more than a year after heralding the engineering leadership of Lars and Jens Rasmussen at the Google Wave Developer Preview at Google I/O 2009, Google now sets the high water mark for the familiar rapid prototyping mantra

fail early, fail often.

What’s to be learned from the demise of Google Wave?

What is the Google ethos? The Google ethos, lifted from my post Lessons From the Google Rocket, is

  • Have the audacity to be different
  • Maintain a healthy distrust for suits
  • Let data be indicators that trump notions
  • Release early and learn

One demonstrably productive prejudice that pervades Google group-think is

Stuff gets invented by engineers, not hucksters or charlatans.

Google values the engineering method. To an admirable fault, Google pursues an engineering-centric path. Introducing Google Wave inventors Lars and Jens Rasmussen to the Google I/O audience, Google Engineering VP Vic Gundotra extols the Rasmussen brothers’ engineering chops, gushing about the Rasmussens’ previous triumph, Google Maps.

Few companies do more than Google to feed the engineering pig. Google are legendary in engineering circles.

Usability Gets Short Shrift

Unfortunately, product usability at Google gets short shrift. Usability of Google products is often relegated to lipstick on a pig. Google is remiss in dismissing interaction design – usability – as lipstick.

As one who occasionally muses about burning his TV remote in a flaming, ball of confusion effigy, I believe

Usability is as fundamental to any product as any whizz-bang functionality

Google Wave was an engineering triumph – a creative mash-up of tried and tested technologies like XMPP and established web concepts like Wiki. However, usability was never improved. User experience was never demonstrably considered by Google. Most users just didn’t get it.

Perhaps the engineering tent at Google needs to include interaction designers. Why not?

Google could even refer to these insightful creative-types as “usability engineers”. Heck, the folks at Cooper, some of the most talented interaction designers on this hairball, are only 30 miles up the road from the brain trust ensconced at the Googleplex.

As cyber buddy Ergun Çoruh says in RIP Google Wave:

Google Wave was too stressful to use.

What Worked… At the Google Wave Developer Preview held at Google I/O 2009, Google VP Vic Gundotra said, “Frankly we need developers to help us develop this product”.

The strategy to release a half-baked concept to the open source community is laudable. The ink wasn’t dry on the Federation spec when eager developers attended the Google Wave Hack-a-thon in June 2009.

Developers were jazzed to get in the ground floor building. Bullish on the potential uses for Google Wave, I wrote Google Wave and Collaborative Projects and Will Google Wave Overtake Microsoft Groove?. With the advent Story Board for Google Wave, I was hopeful that the Agile community finally had a software tool that helped rather than hindered.

  • Half-Baked Product
What Didn’t Work… For execution metaphors & ease of operation, Google Wave was the TV Remote of collaborative software. It was a pinball waste-land of bells & whistles.

Many of the operational metaphors that make things easy for users to understand were never explored or realized for Google Wave.

Why did Microsoft Bob, an epic product failure, last longer than Google Wave? Perhaps because it used the familiar metaphor of a house with rooms.

Google Wave vs. Google Maps: Google Wave was bereft of metaphors to guide skittish users. One reason Google Maps is wildly successful for inventors Lars and Jens Rasmussen is because online maps have a direct and familiar analog on paper. The Rasmussen brothers didn’t enjoy the same advantage with Google Wave.

  • Half-Baked Product

Google will bake the lessons-learned into future forays into social networking and collaborative apps. Perhaps we’ll see user experience improvements in Google’s upcoming Facebook-killer Google Me?

Prepare for Informed Improvisation

Software developers, like many mammals, are sheep-like and slow on the uptake.

We spent the better part of a decade celebrating our avoidance of Big Design Up Front (BDUF).

I jumped on the Agile Software Development hay-wagon. It was

  • liberating, 
  • professionally acceptable, and 
  • socially, much cooler,

to be Agile.

Agilists like me eschewed BDUF. Our approach to design was emergentWe programmed on the fly.

Yes we were faster. Yes we delivered.

In some cases we moved software into production more frequently than the Milkman delivered milk.

The question I ruminate over is

Did we deliver lasting value?  

The cows are still grazing, but I for one, contributed to several steaming cow pies in the name of agile software development.

The voices I respect in our community suggest we’re avoiding the fruits of experience design considerations at our peril. Sorry Milkman, but delivery isn’t everything.

Software Delivery is the milk jug, NOT the experience of gulping cold, fresh milk

There are signs our community is moving beyond the ominous clouds of Deliverence – pun intended – toward reasonable preparation & design discovery.

Building Benches
Design is premeditation. It is never an immutable concept. It is never written in stone. Ideally, my premeditations grow with me into active (perhaps subconscious) meditation during execution whether programming or building benches.

Last weekend I built a cedar bench. Much thought was devoted to who would be sitting on the bench BEFORE I cut wood. I considered comfort and aesthetic appeal. I chose a height of 19″ following simulated user acceptance tests. I made a sketch. I thought about the materials in the context of human contact (choosing naturally rot-resistant cedar over treated lumber).

Our golden retrievers Lucy & Libby seem to be turning their noses up at my handiwork, but my family likes it. I had premeditated design considerations, but allowed myself the freedom to adapt on the fly.  

For me, these up-front considerations, design, or call it what you will, are no more than sound preparation.

Sound Preparation

Sound preparation is not the same as BDUF. I prepare to build something with the tacit understanding I will adapt as the unforeseen emerges.

Sound preparation allows for informed improvisation

Like performers, well-prepared programmers are freer to improvise because preparation considers eventualities – not all eventualities, but some. Preparation frees us to be creative without mucking things up, even if all we start with are a few baseline considerations like

  1. Who’s going to use it?
  2. What do they need?
  3. What do they like or dislike most?

I want to be open to discovery. I want time for up-front user research. I want time to respond to user feedback. I want clear and verifiable benchmarks of value. I want enough information about users and benchmarks of value to allow for informed improvisation once the building commences.

Is Version One a Software Chindōgu?

Chindōgu is the act – some would say art – of creating a product whose usefulness is precluded by its absurdity.

Chindōgus are not absolutely useless, since they typically solve a problem; yet in practical terms, chindōgus are much more humorous in their inherent absurdity than they are useful.

The Japanese word chindōgu means unusual tool. Chindōgu, and its inventor Kenji Kawakami, were featured on the BBC television show It’ll Never Work.

How many software chindōgus are you aware of ?

Our team is consistently bewildered, confounded, and confused trying to use Version One to plan and track iterations and work tasks. This isn’t a rant about Version One. Maybe Version Two will provide tangible value….who knows?

If you have a Version One success (or failure) story,

Or, if you have a Software Chindōgu to share…
Please post a comment!

Donald Norman’s case studies in The Design of Everyday Things awaken us to the successes and failures of everyday things from the standpoint of usability. Software professionals involved with user interfaces would do well to read Norman’s book if only to re-sensitize themselves to the user’s experience.

As software professionals, we should strive to grow software that is well-thought out and cleverly usable — not spawn software oddities suitable for chindōgu museums.