Festering Manifestos - What is Software Quality?

Referring to The Manifesto for Software Craftsmanship, product development executive Charl Dreyer asks

Is another manifesto necessary?

The Manifesto for Software Craftsmanship offers up quality addenda to the Manifesto for Agile Software Development. Charl Dreyer wonders if this is necessary (see Dreyer’s Raising The Bar).

Robert Vitello, CIO at New York State Labor Department, says

Although well meant, the Manifesto for Software Craftsmanship seems too unspecific to have real value on the ground. When such pronouncements are too lofty or too general, they are subject to the kind of variable interpretation that cause the authors to rail against the original Manifesto.

I agree with Robert’s critique. There is not much mental traction served up by platitudes like steadily added value or productive partnerships.

Nonetheless I signed The Manifesto for Software Craftsmanship because I support the intent.

If quality is sufficiently defined, who would be anti-quality?

It is perhaps important to remember that

the quality of something does not necessarily determine its value

Something might be good because it is useful, because it is beautiful, or because it exists. I like the aesthetic appeal of sparse but powerful code -- one or two lines of code that does a lot - but I can't assert that it always provides economic value. Sometimes we favor elegance over expedience; not always providing demonstrable economic value. We are employed in the software business to increase economic value.

The craftsmanship addenda to the agile manifesto are born from noble purpose. Open-ended, nearly inscrutable bromides like “well-crafted software” are potentially helpful insomuch as they can promote collective examination and collective improvement. Yes, examination and improvement are good! Lofty, intellectually fuzzy declarations are potentially helpful insomuch as they promote thought about-, and discussion of-, elusive terms like “value” and “quality”.

I like the concept of a team-level “craftsmanship contract” during chartering. I took a swing at this topic a while back in my post Team Manifesto - Craftsmanship, Behavior & Minutiae. Creating a craftsmanship contract starts with the open-ended question

What does software quality mean to you?

The goal is to end up with testable assertions. That is, to end up with prominently displayed bullet points that are meaningful to the team and testable in retrospectives.

What constitutes software quality?

Is software quality a personal matter or is it a collective concern of the team? I would like to hear your thoughts.

Will Google Wave Overtake Microsoft Groove?

The reception attendant at my community gym scanned my membership card.

He then observed me stuffing a 1/2 inch lithology of plastic commerce back into a 1/4 inch slot in my wallet.

"You should carry fewer cards", he suggested.

"Or get a bigger wallet", I said.

"If you get a bigger wallet", he said, "You'll only need a bigger pocket."

A googolplex is 10^googol. For carpal-tunnel-free typers with an aversion to acronyms, it is also expressed by a 1 followed by a googol of zeros. This prosaic number should not be confused with the audacious googleplex. Googleplex, a pretentious, self-satisfying wordplay on an ordinary - albeit large - number, is the name of the corporate headquarters of Google.

The Googleplex is situated on a huge 26-acre campus in Mountain View, California. It is built on Brownfield land and populated with smart, un-jaded, and largely under-30 geemers working on "pet projects". As a graybeard with a cheesy pedigree and disappearing gray matter, Google is a lofty place that wouldn't hire me even if I purchased, set, and tuck-pointed all of the gold bricks needed to line the hiring manager's koi pond.

If you have occasion to visit the Googleplex, skip the nutritionly-bereft continental breakfast at your Comfort Crib and proceed directly to Joanie's Cafe (kitty corner from Stanford University in Palo Alto).

My yet unabated prejudice is that some of the projects being worked on at Google are more grounded in the real-world than others.

Nonetheless, I traveled to and spent the early part of last week at the Googleplex with my business partner Garry Smith to learn the secret handshake and to dig into Google's new collaborative software Google Wave (see Ben Parr's Google Wave: A Complete Guide).

At its core, Google Wave is an extension of XMPP (Jabber). Wave is not a mature product. Google is open-sourcing its development. So far, there are implementations in Java and Python.

I have been exploring a preview of Google Wave via my sandbox account on FedOne hosted by Google (ping me at bmacneal@wavesandbox.com).

Google Wave has a polling widget called Polly. At the Google Wave hackathon, I included Polly in a Wave thread. I triggered the Wave with the question

Will Google Wave Overtake Microsoft Groove?

I assumed that not many people, other than Microsoft Chief Software Architect Ray Ozzie and a few Microsoft devotees, had heard of Microsoft Groove. I also assumed that most people attending a Google gathering might harbor unfounded ill-will toward Microsoft.

I wanted to test the Polly polling widget, so I wanted a provocative question. I invited the Google Wave disussion group (wave-discuss@wavesandbox.com) to the thread.

After a few unseemly burps, Polly worked like a charm. One could see live updates in the Wave including the commentary (or blips in Wave parlance) of the poll participants. Wave blips and voting peaked after Garry posted a link to a June 09 interview Ozzie at the Bat where the Microsoft oracle and Groove inventor, Ray Ozzie, opines about Google Wave (e.g., "its complexity might curb its adoption").

Of the 150 or so attendees at the Google Wave hackathon, 92 people indulged me by voting and sharing their opinions. Polling is still open, but if you want to weigh in, you'll have to post a comment below or apply (subsequent plead and re-apply) for a sandbox account.

Poll Results

Will Google Wave overtake Microsoft Groove?
Yes	73
No	3
Maybe	16

I don't know what my over-stuffed wallet encounter with the attendant at my gym has to do with this post other than its parallel to my quest for finding a wagon to hitch to...only to remind myself that

everyone is looking for a bigger wallet, perhaps forgetting that they'll soon need bigger pants.

Of Interest

See video of Google Wave on a iPhone.

Software Teams, Comedic Improvisation, & Acceptance

Improvisation is an intuitive, coordinated, and spontaneous response to dynamic events. Improvisation is widely used in comedy, music, theater, and dance.

How might the techniques of improvisation be used in software teams?

In Blink, Malcolm Gladwell, author of the best-seller The Tipping Point, examines the structure of spontaneity. Gladwell observes that one of the critical rules of comedic improvisation is that the characters in skit accept everything that happens to them. He refers to this as the rule of steadfast acceptance.

Improvisation and Acceptance

Gladwell illustrates the role of positive acceptance with two improvisational comedy skits using the same comedic actors playing a doctor and a patient. The initial setup for the skit is that the patient's leg is in pain. The first skit has a funny line, but quickly stalls out:

Patient: I'm having trouble with my leg.
Doctor: I'm afraid I'll have to amputate.
Patient: You can't do that, Doctor.
Doctor: Why not?
Patient: Because I'm rather attached to it.
Doctor: (losing heart) Come on, man.
Patient: I've got this growth on my arm too, Doctor.

Both actors become frustrated because the improvisation stalls abruptly. Why? Because the doctor offers a suggestion, "I'll have to amputate", but the patient rebuffs the suggestion, saying "You can't do that, Doctor"

The following skit that Gladwell uses is more sustainable because the comedic actors agree beforehand to accept rather than negate any turn of events:

Patient: It's my leg, Doctor.
Doctor: This looks nasty. I shall have to amputate.
Patient: It's the one you amputated last time, Doctor.
Doctor: You mean you've got a pain in your wooden leg?
Patient: Yes Doctor.
Doctor: You know what this means?
Patient: Not woodworm, Doctor!
Doctor: Yes. We'll have to remove it before it spreads
(Patient's chair collapses.)
Doctor: My god! It's spreading to the furniture!

The first skit peters out to a pre-mature end. The second skit opens up with possibility.

Steadfast Acceptance

How might our software teams apply Steadfast Acceptance to paired programming, architectural decision-making, or iteration planning?

Listen to - and carefully consider - your teammate's suggestions

Has your suggestion been rebuffed while pairing on a programming task, or while a participant in a decision-making meeting, or while participating in planning an iteration? It's a mojo-killer. Many people squash ideas with uncanny regularity. It's destructive.

Should we consider taking our cue from actors trained in comedic improvisation who

accept all offers

to move the skit forward? Should we accept that none of us are truly smart enough to anticipate where our software skits will go?

Unilateralism is the bane of teamwork. I once worked with a talented programmer who consistently countered any suggestion or observation I made. It was baffling. To break the logjam I tried magnanimity. I enthusiastically agreed to his assertions, even when I thought my suggestions, or the ideas of others, had promise. It became poisonously unproductive. I resented his autocracy. I resented his lack of respect for alternatives. It clouded my acceptance of his best ideas.

Comedic improvisation teaches us to

• Open ourselves to occasionally ego-compromising risks
• Adapt to the immediacy of change with mindfulness
  
• Improve our concentration skills
  
• Improve our listening skills
• Examine our responses to suggestions
  
• Recognize that rebuffing suggestions is a mojo-killer
• Consider steadfast acceptance as a practice (i.e., accept rather than negate a suggestion or a turn of events)

Tweet this post

Google Wave and Collaborative Projects

My tea kettle is whistling with more than lukewarm ideas on how we might use Google Wave for collaborative software projects.

To separate the steam from the high-pitched whistle of market evangelism...

Google Wave is a communication platform.

How might we use a real-time communication platform to make the push-pull of our collaborative software projects easier?

The Google Wave model promises to be a comfortable fit for seeding and feeding post-agile software projects. We might use Google Waves for

• Generating user stories
• Planning iterations
• Estimating tasks (e.g., real-time planning poker)
• Managing task boards and
• Spawning dashboard artifacts like burn-down charts

I like its threaded conversations of wavelets, blips, and drag-and-drop multimedia. Some Google Wave features that should make collaborative software projects easier are

• Bots and Gadgets Developers can embed gadgets and build robots that automate tasks within a Wave. A robot might read the content of a wave and then perform an action.
• Drag-and-Drop Sharing - Unlike clunky email attachments, you just drag-and-drop screen prints, wire-frames, buttons, stock photos, etc. on a Wave.
• Wiki-like, Hopefully Better - Anything within a Wave is editable by others. One may correct, append, or add commentary. One can only hope this is where project artifacts live rather than die (as with many project Wikis).
  
• Real-Time - See what your teammate is typing, character-by-character, unless it's planning poker - in which case you'll have to close your eyes.
  
• Playback - Playback any part of a Wave to see what the SME actually said about how something works.
  

The immediacy of instant messaging, combined with the richness of an anabolic Wiki, might prove to be a worthy collaboration tool. I like the concept of having team-member participation in threaded conversations (a traditional bulletin board), but also having features like playback and custom-robots that interrogate Wave content to perform actions.

The possibilities heat my water to boiling point. Robots are like having another person participate in a Google Wave conversation, except that they’re automated and they operate on the content of a wave. All extensible by common day-laborers like me.

The actions spawned by a bot might range from notifications like build failed or single sign-on test succeeded to spawning wavelets of unit test methods that are peppered with scenarios plucked from business-side requirements, discussions, and feature assertions.

Imagine a bot that parsed a business thread for Behavior Driven Development keywords like

As persona [X}
I want [Y]
so that [Z]

AND, parsed a business thread for scenario keywords like

Given initial context,
When an event occurs,
then ensure some outcomes.

then spit out a unit test methods?

Challenges to Adoption

Widespread adoption of a technology-driven phenomena like Google Wave will likely have to first hurdle cognitive and social models in search of digestible user metaphors (see Adina Levin's excellent post Google Wave: still in the lab, potentially mindbending for adoption).

Many of the operational metaphors that make things easy for users to understand simply don't exist for Wave yet. The Wave model mashes the familiar (email threads, wiki documents, and streaming communication) together. Instant messaging in your favorite messaging client is an easy model to follow. It is a simple post, response, & repeat. Will a multimedia, multi-participant Wave be so straight-forward? How will users find content efficiently? How will users invited into to a Wave conversation get up to speed with the other participants? Wave touts a replay feature, but is that the most efficient thread content primer?

More...

• Shannon Greywalker's Google Wave changes everything you know about agile collaboration and technical documentation.
• Ben Parr's Google Wave: A Complete Guide.
  
• Abel Avram's Google Wave’s Architecture.
• Google's Google Wave API.
• Spread Google Wave's Sandbox Developers Preview and Understanding Google Wave Development Part 1.
• Google Wave Interest Group on LinkedIn.