Exploration Through Example

Alistair Cockburn:

I’ve had to be part of and lead collaborative work sessions. People remark on the strong feeling of collaboration during those meetings, and the speed at which we get results. Other skilled facilitators manage the same. People ask us how we achieve these effects and whether it can be learned. With this article, I hope to show how we achieve these results, and that they can be learned. […]

In the end, three dominant categories of actions appeared. They are:

• Lift others
• Increase safety
• Make progress

Minor categories also showed up:

• Add energy
• Build personal relationships
• Create an identity

I am at best an amateur facilitator so this will be a handy checklist / self-retrospective-list for me. My biggest problem is dealing with what Sam Kaner calls “the groan zone“—the place where progress seems stalled and the group can either move through it or (more likely) fall back. At that moment, a whole bunch of people and ideas are in unstable equilibrium. What I’m not so good at is keeping the strongest personality in the group from tipping the equilibrium to a solution that meshes best with their personality. (Sometimes I’m that person.) Since, as Mencken said, “There is always an easy solution to every human problem—neat, plausible, and wrong,” it’s important to hold the balance.

That’s why I’m most comfortable with situations where we can agree to stop for now, go off and do an experiment that makes us know more. That’s not always possible—and, whenever it is, it requires convincing people to stay in the groan zone indefinitely.

Jason Gorman:

Contrary to - well - pretty much the entire software industry, I don’t believe that a software architect is someone who designs software. I believe that a software architect is someone who recognises a good software design when he sees one.

A Rails homage to the “I’m a Mac” commercials (via /\ndy)

The Wall Street Journal published an editorial containing this graph:

In what possible universe could you honestly fit that curve to that data? Who could, without shame, publish a curve that goes around the bulk of the data? One that goes through an obvious outlier? (Tukey’s brilliant and eccentric Exploratory Data Analysis counsels us to understand outliers before worrying about the “central tendency”. I wonder if the anonymous editorialist wondered what might be special about Norway? Perhaps a particular natural resource, drilled from under the ocean? If only there were a tool one could use to find information about that resource’s contribution to Norway’s GDP or any special tax rate applied to it!)

But, self-doubting liberal that I am, I can’t only conclude that unsigned Wall Street Journal editorials are written by people whose preferences and loyalties have made them—to use the precise academic terminology—bullshitters, people to whom the truth is completely irrelevant. I have to wonder to what degree I do the same thing, to what degree my own comfort and self-interest has led me to push back against the whole post-Agile thing, despite my respect for Jonathan Kohl and Jason Gorman.

Fortunately, I have morphing software to play with, so I can cut self-reflection short.

Hat tip to Economist’s View

For many web apps, it’s important to get the user’s workflow right. Consider a Rails app that uses some variant of acts as authenticated to handle user registration and login. Here’s one way of describing an example of normal registration:

John visits the home page.
John follows the “sign up” link.
(John is now on the signup page.)
John signs up as “john”, email “john@example.com”, password “sloop”.
(John is now on the welcome page.)
John waits for activation email…
John clicks on a URL ending in an activation code.
(John is now on the login page.)
John logs in as “john”, password “sloop”.
(John is now on the member page.)

Here’s another:

Which is better? If I were trying to design the workflow—get it so that it’s right for the users—I’d much rather use a picture (whether drawn in OmniGraffle, as this was, or on a napkin or whiteboard.) Why?

1. It’s easier to “zoom out” from a picture, to ignore the details. When I do that, I’m more likely to notice missing workflows or stupidities in the ones that I have.

2. As a designer, I’ll soon have to explain my thinking to others. It’s easier to explain a picture because it’s sitting right there in front of both of you, visible in two-dimensional space. It’s simple to refer to something you already mentioned: point at it. A wealth of context gets recalled by that simple gesture. If it’s not readily recalled, you can decorate the graphic with something that jogs the memory. Pictures make for a much more fluid way of communicating.

3. Our minds are in bodies; and bodies have minds of their own. We think kinesthetically and visually, not (just) by banging propositions together according to the rules of some kind of logic. The more ways you think about something, the fewer mistakes you’ll make.

But there’s one big disadvantage of pictures from the point of view of the test-driven (behavior-driven, example-driven) programmer: they’re not executable.

I’ve released an alpha version of an open-source library that converts such pictures into Ruby tests. Below the fold, I show how the workflow picture becomes a Rails integration test.

✂——✂——✂——✂——✂——✂——✂——✂——✂——✂——
Read the rest of this entry »

Confused of Calcutta writes about risk and Agile:

Once you switch focus from content to process, agile techniques don’t stand a chance. Agile in a “content” perspective leads to the Baconian “A man that starts with doubts shall end in certainties”; agile in a “process” perspective leads to the other Baconian statement “A man that starts with certainties shall end in doubts”. These two positions are polar opposites.

As Douglas and Wildawsky stated, people act as if they know the risks they face despite not knowing them; they then disparage people who act to discover and potentially mitigate hitherto unknown risks. The Emperor’s New Clothes.

More later.

I’ll be looking for what’s coming. This reminds me of one of my themes about Agile: that it’s about acting to change the context more than it is about adapting to a context. What Mr. Rangaswami brings to my mind is the degree to which that context is always unknown.

As far as I know, there’s only one other person in the world who cares about testing Rails apps from OmniGraffle documents. (Hi, Tom!) Still, since I always make a fuss to clients about how important it is to reinforce discipline and ease the release process by frequently releasing potentially usable product as widely as possible—and since I believe what I say—it’s time for a release:

The first, minimally bearable version of my OmniGraffle parser/decorator is available for download. You can also read the documentation online.

Carnival of the Agilists is a useful multi-person roundup of Agile news. You can subscribe here. More here.

On a lighter note, I’ve decided to make up exampler.com t-shirts, posters, and whatnot. Since I want them to help rally the masses behind my recent themes, I’m going with a Soviet propaganda poster sort of style. In order to offend the shade of that monster Stalin (who forced the style on Soviet artists), I’ll sell these trinkets online (eventually), have my children do fulfillment, and let them pocket the profits—thus encouraging them in capitalism (not that they need it).

Here are two rough mockups. Which do you prefer?

The United States spends almost as much on the military as the rest of the world combined. That will continue.

To be taken seriously by the chattering and political classes, one can’t heed George Washington’s unmanly plea that the US avoid “permanent, inveterate antipathies against particular nations” nor the way Madison favored eggs over omelets when he wrote that “No nation could preserve its freedom in the midst of continual warfare.” In a world of talk, a world of strutting and posturing, no national politician can afford to show “a reluctance to travel a long distance to kill foreigners at great expense” (Jim Henley’s pointed definition of the modern meaning of “isolationism”).

In the world of reality, though, war means horrendous wounds and families desperate to find ways to be with their loved ones while they recover as much as they can. The charity Fisher House…

… donates “comfort homes,” built on the grounds of major military and VA medical centers. These homes enable family members to be close to a loved one at the most stressful times - during the hospitalization for an unexpected illness, disease, or injury.

There is at least one Fisher House at every major military medical center to assist families in need and to ensure that they are provided with the comforts of home in a supportive environment. Annually, the Fisher House program serves more than 8,500 families, and have made available more than two million days of lodging to family members since the program originated in 1990.

I will match donations to Fisher House made between now and July 21, up to a total of USD1000. Email me a copy of your confirmation. After July 21, I’ll mail confirmation of my donation to John Rogers, who’ll match it again.

UPDATE: John Rogers reminds me that Don Murphy will also match. Your $25 donation would turn into $100.

Good points, entertainingly written, by Jason Gorman.

Since he’s a programmer enthused with testing, and allows exploratory testing in his worldview, and is in cahoots with Jonathan Kohl, I hope he figures out exploratory testing at the xunit level. The very flow that TDD provides acts as blinders on my ability to see anything other than my current path. I have to pull back and shift focus. I don’t know how to do that well.

For example, I just added groups to my fledgling Graffle parser. Previously, the object at the end-point of a line had to be at the same nesting level as the line itself (since there was only one level). When I wrote the code to find the end point in a multi-level document, a test that surprisingly didn’t pass after I wrote the code made me realize a null check needed to be a responds_to? check. I made the change and moved on.

Is that all I should have realized? Maybe the unexpected failure means that there’s something odd in the way I’m thinking about things that are Nestable and things that are Containers and things that are both. But how do I know, at a particular point, whether I should stop to think or move on? And how should I think when I stop? What’s the equivalent of the mnemonics and rules of thumb that James Bach and Michael Bolton are famous for?

More than a decade ago, I had some modest heuristics in my The Craft of Software Testing. But those were derived from looking at bugs in big chunks of C code, and they were concentrated on the question “did the programmer do what she intended?” Today, that question is (among better programmers) “yes” often enough that different ones have become more prominent: “has the programmer grasped the problem? has she intended to do the right thing? what has she overlooked?”

More research is needed. More discussion, too. Another excuse for a mini-conference.

Suppose you’re a person with a bad short-term memory doing test-driven design. (You’d be me.) You’d want to have both the test source and corresponding product code source visible at the same time, and probably several other files as well. Here’s a mockup of such a configuration:

To this novice user, TextMate doesn’t seem like it wants you to be doing that. For example, apple-t doesn’t remember visits to separate windows, so when I want to visit “that file I was just in”, I have to remember whether it was in a tab or a window and use either apple-t or apple-`. But the reason I have separate windows is I have no memory for such things.

However, I’m early enough in the Emacs->TextMate switch that I’m sure I’m missing many things. How do you use TextMate on big screens? I couldn’t find stories on the web, so perhaps this blog entry can help the next person searching “textmate big screen” or “textmate cinema display”. Even better, I’ll make screencasts of tricks and put them on the TextMate wiki.