Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Wed, 19 Apr 2006

Pair programming with users

An interesting story about pairing with users to implement new stories. I found it intriguing because it repeats some of my hobbyhorses from a different perspective (that of an APL programmer). Notice that he gives up on English in favor of examples. Notice also the adaptation of a programming language into a more-ubiquitous cross-domain language. (This made easier by the close fit APL starts out with.)

The part of the story about moving processing in from a distant site reminds me of what I've started calling a service-oriented development strategy. The idea is to forget about the program as an object but rather think of the project team as providing a repetitive service to the user base. In the company described in the link, someone—probably the product director—would funnel claims to process into the team. One person on the team would be an expert in manually processing claims. She'd be a bottleneck, so she'd enlist other available people—the programmers—to handle the simpler claims. Programmers being lazy, they'd quickly write code to make repetitive parts of the task go away. They'd also (and thereby) learn the domain. As they did, they could handle more complex claims, which would lead to more capable code. Lather, rinse, repeat.

Now, the truly lazy service person won't want to even type information into the program; she'll want the users to do it themselves. That means seducing the users into trading the ease of just forwarding a claim to the team for the benefit of higher throughput. So now—and only now—the programmers have to focus on making the UI usable by normal humans. First, they'll make it good enough for those few technology enthusiasts among the users. Then they'll improve it enough for the pragmatists and even the conservatives. (Thus, the standard high-tech adoption lifecycle is followed within a single project.)

At some point, you run out of claims that the product director thinks should be automated. So you stop and send the programmers off to do something else.

I've not convinced anyone to actually try this. I probably never will.

(Note: This strategy doesn't really match the story, since the users do nothing but claims processing. It's probably better suited to situations where the software is a necessary but non-central part of the job.)

One immediate objection is that this will lead to a lousy, patched-on-after-the-fact UI. For what it's worth, Jeff Patton (Mr. Agile Usability) doesn't think that's necessarily so. In fact, when I talked to him about it, he said that committing to a UI too early can hamper the project if there's not been time yet to incrementally make a decent model of the users' world(s).

## Posted at 07:35 in category /links [permalink] [top]

Mon, 12 Dec 2005

UI design links from Jared M. Spool

What makes a design intuitive? is nice and readable short article about the two ways to make an interface that people will call intuitive.

Designing embraceable change is a follow-on that talks about how to introduce a new UI to an existing community. This has relevance to Agile projects that are continually tinkering with the UI.

The series ends with The quiet death of the major relaunch. Here's a trivial example of the approach:

At eBay, they learned the hard way that their users don't like dramatic change. One day, the folks at eBay decided they no longer liked the bright yellow background on many of their pages, so they just changed it to a white background. Instantly, they started receiving emails from customers, bemoaning the change. So many people complained, that they felt forced to change it back.

Not content with the initial defeat, the team tried a different strategy. Over the period of several months, they modified the background color one shade of yellow at a time, until, finally, all the yellow was gone, leaving only white. Predictably, hardly a single user noticed this time.

The key point in this last article is this:

Our findings show that consistency in the design plays second fiddle to completing the task. When users are complaining about the consistency of a site, we've found that it is often because they are having trouble completing their tasks.

## Posted at 10:22 in category /links [permalink] [top]

Thu, 21 Oct 2004

What? - Gut? - So what? - Now what?

Esther Derby ran a BoF on retrospectives. She's written up her notes.

One of the things she talked about was a model of communication that she uses. It's summarized by the four questions in this posting's title. At a recent meeting, I compared something I'd just heard to those four questions and was inspired to do something I haven't done in many years: get so uncomfortable speaking to a group that I had trouble finishing.

Believe it or not, that's a recommendation. I have a fear of spending so much time in my comfort zone that I turn into one of those dinosaur consultants I scorned when I was young and fiesty. (Still do, actually.) I get uncomfortable whenever I notice I've been comfortable for a while.

## Posted at 09:00 in category /links [permalink] [top]

Mon, 22 Mar 2004

Links

A blizzard of ideas this time, all suggestive, none that I've been able to comment on sensibly.

• Martin Fowler on specification by example.

• Chad Fowler on minimalism.

• Ben Hyde on solving hard problems. "... we complain: the design should be more elegant, the parts more modular, guiding principles of the design less random, the coordination problems less tedious. These complaints are the symptoms of the hard high value problem."

• Ben again on a clever hack that solves the Turing test.

• Ben, again, on creating a public good.

• Alan Francis on coaching.

## Posted at 16:59 in category /links [permalink] [top]

Wed, 17 Mar 2004

Links

Jonathan Kohl has posted a copy of an article of his on developer/tester pairing.

Jason Yip suggests losing the term "agile":

"Agile" is not test-driven development, continuous integration, simple design, whatever; it's any feature, any order, most valuable feature first.

Part of the purpose of the workshop that led to the Agile Manifesto was to find a replacement for the term "lightweight processes." People felt that saying "I'm a Lightweight!" somehow didn't get the right message across to Gold Owners.

"Agile" was certainly a success in those terms. Jason suggests it might have been too successful now that everyone's piling on.

Perhaps, though I do think there are other unfortunate terms to go after first.

However, Jason's definition doesn't capture two of the values the Manifesto documents:

• individuals and interactions...
• customer collaboration...

Jeffrey Fredrick on confidence due to tests.

And related: Alberto Savoia with some history of a testing tool company that's eaten its own dogfood. (Disclosure: I've done consulting for Agitar.) I was particularly interested in the effects of their dashboard, both good and bad. I remain wary of numbers. My normal preference is for dashboards and Big Visible Charts that are perceptual, fuzz out the precision in the data, and present the results of exploratory data analysis. But lots of numbers make it harder to game the system (consciously or unknowingly), and using the numbers in a system filled with human feedback ought to make them self-correcting.

## Posted at 11:56 in category /links [permalink] [top]

Sat, 21 Feb 2004

Children were created by viruses to make replication easier

Actually, this posting has nothing to do with that, but think about it. Why contend with adult immune systems when you can use immature ones? I imagine two viruses brainstorming a billion years ago, when one of them says, "Sexual reproduction!" And the other says, "Yes! And while we replicate within the hosts that have incompetent immune systems, the other hosts will nurture the cells we're using! Boris, you are brilliant!"

That interlude brought to you by Sophie "Why?" Marick. And, soon, no doubt, her brother.

Now that Dawn's home, I should be doing the things I should be doing. But I need a break, so I read some blogs. Here are two nice pieces from Dave Thomas. Both contain coolly idiomatic Ruby.

• On code generators. (Via Jon Udell.)
• Lazy typing - "first type in wins".

P.S. The disciplinary agency piece is coming along, but the walking-through-refactoring example is 17 pages of test tables and code and pictures and text. This seems a problem.

And the Powerbook mysteriously stopped ticking three days after I whined about it. Magic.

## Posted at 10:12 in category /links [permalink] [top]

Mon, 24 Mar 2003

How do you get to Carnegie Hall?

Chad Fowler has written a piece inspired by PragDave's essay on "artifacting". Chad writes:

there is one particular aspect of practicing "art" which seems conspicuously missing from the every day work of the programmer. As a musician, I might spend a significant portion of my practice schedule playing things that nobody would want to listen to. This might include scales, arpeggios, extended tones (good for improving control on wind instruments, for example), and various technical patterns.

This idea of practice has been a theme of Dick Gabriel's in recent years. Here's an abstract for a talk he gave at XP/Agile Universe 2001. The talk was titled "Triggers & Practice: How Extremes in Writing Relate to Creativity and Learning".

The thrust of the talk is that it is possible to teach creative activities through an MFA process and to get better by practicing, but computer science and software engineering education on one hand and software practices on the other do not begin to match up to the discipline the arts demonstrate. Get to work.

A final link: at an OOPSLA workshop on constructing software to outlive its creators, PragDave brought up the idea that we should be more ready to throw out our work and rewrite it. That ties in to a story Dick tells of the poet John Dickey. Here it is, from Dick's book Writers' Workshops and the Work of Making Things:

Dicky had numerous methods of revision. His favorite was redrafting, in which he would create new drafts of a poem until there were literally hundreds from which he could choose... Dicky viewed his process as one of experimentation. In the end, when he had hundreds of versions and drafts of a piece, he was able to choose from them. Surely some of them were better than others, and if he chose one of those, he was better off than he could have been.

PragDave inspired me to start throwing out and rewriting code, but I've done little of it yet. Unlike Dickey, I keep tweaking and tweaking and tweaking the same piece. There's never enough time to do it over, but there's always enough time to do it right...

## Posted at 15:13 in category /links [permalink] [top]

Two interesting reads this morning

Laurent on the principle of legitimate curiosity. How can you use questions about encapsulation to drive thoughts about what the real problems are?

PragDave on artifacting, our tendency to think too much in terms of nouns, too little in terms of verbs. That's also a hobbyhorse of mine. (Hence my slogan: "No slogan without a verb!")

Reading Dave's piece, I realized part of the reason I like verbs. We think of actual things in the world - rocks, trees, etc. - as standing alone. They are what they are, independent of things around them. That property we see in concrete objects is carried along into language, where we apply it to very abstract nouns like "requirements" and "quality". Those are not actual things, and they do not stand alone in any meaningful sense, but the conventions of language let us treat them as if they were and did.

In contrast, verbs customarily don't stand alone. In sentences, they take subjects and objects. Contrast two conversations.

Betty: What did you work on this morning?
Sue: Quality.
Betty: Ah... So, where to for lunch?

Betty: What did you do this morning?
Sue: Coded.
Betty: Coded what?

Now, in the second conversation, Betty could have skipped the followup question. And, in the first, Betty could have said, "What does it mean to work on 'quality'?" My point, though, is that verbs pull you to ask the next question, to look for subjects and objects and connections, whereas nouns make it perfectly easy to stop asking. Since one of our problems is that we stop conversations too soon (including our interior conversations), consciously using a lot of verbs helps us.

But now I must head back to the taxes... Why is it that a crash in a tax program is so much more disturbing than a crash in the operating system?

## Posted at 08:00 in category /links [permalink] [top]