Exploration Through Example

It’s important to have catchy ways to tag ideas with. One good idea, well-tagged, is Gilbert Ryle’s distinction between “knowing how” and “knowing that.”

I used to play a game with my daughter when she was around eight. I’d ask her to define a peanut butter sandwich. She’d say something like “bread with peanut butter on it.” I’d say, “So if I take a slice of bread and put a jar of peanut butter on it, that’s a peanut butter sandwich?” She’d say, “No, it’s a piece of bread with peanut butter spread on it.” And I’d say, “So if I spread peanut butter on both sides of a piece of bread, that’s a peanut butter sandwich?”

This game can go on for a long time.

I was of course trying to teach her that there is no such thing as an unambiguous requirement. Ambiguity is a three-way relationship between a reader, her conception of the writer, and the text.

“Her conception of the writer”: to some people, a peanut butter sandwich has two slices of bread. The raw statement “get me a peanut butter sandwich” is ambiguous until you know which kind of person uttered the statement.

A lot of knowledge of the writer/utterer is not conscious, because conscious thought is inefficient. We spend a lot of time just knowing that other people know that we know what they want. When Sophie asks for a peanut butter sandwich, I short-circuit any consideration of what a peanut butter sandwich really is by knowing what she wants and knowing what past actions have caused her to be satisfied.

That’s part of the reason why requirements are most efficiently transmitted face-to-face.

UPDATE: Joseph Bergin contributes a requirement that depends critically on shared background knowledge and a willingness to overrule the literal meaning:

I’m going to give a TDD demo at a C shop. I’d rather do it in C than in Java or Ruby. It’d be best to build on an existing suite. Do you have any well-unit-tested, open source C code to suggest? To match what they do, a library would be better than an app; data-heavy would be better than processing-heavy. Objective C would be OK too; I can just ignore the objective part. C++, too. Thanks. Add a comment or mail me.

I believe I heard this story from Ken Schwaber. I’m not sure.

Once there was a team who wanted a bullpen environment, but the Furniture Police wouldn’t let them tear down the cubicles. That was an impediment to the team. The ScrumMaster came in over a weekend with tools, took down the cubicles, and made a bullpen. On Monday, he or she said that if the cubicles came back, they would have to fire her. Impediment removed.

Back in the day, I was heavily associated with the context-driven school of testing. I still honor it, but I do assert that Agile is importantly different. It is context-driving, not context-driven.

That is, probably the key question in the context-driven school is “given my context, what’s the best thing to do?” (See the two-project example at the link above.)

The question in Agile is much more “given my context, what should I change about it to allow me to work more as I please?”

Obviously there’s overlap, blah, blah, blah. But the different emphasis leads to different actions leads to different projects. At least in my case.

UPDATE: Since I link to this post occasionally, here’s an email I sent once that adds a bit to it:

I’ve come to think of Agile as /context-driving/ rather than /context-driven/. This comes up in the perennial debate about whether there should be 100% test automation. A lot of that debate is tedious and silly, but there’s an important facet that too often goes unmentioned. Programmers have reasons for wanting 100% test automation, important among them that programming is less stressful with test support. It is a fact in many projects and code bases that some proportion of tests programmers would like to have automated are not worth automating by any dispassionate standard. The historical context-driven-testing answer to that problem is to accept it and find the best possible blend of automated and manual testing (and to make sure that both are done well). The programmers’ context-*driving* answer is to change the context so that the economics change to make 100% automation economical.

Now, that attempt to change the context could work, or it could not. As it turns out, it’s worked surprisingly well across a broad range of problems, which makes me want to continue pushing in that direction, rather than growing up and admitting some things are impossible.

Rachel Davies recently needed to step down as chair of the board of the Agile Alliance. I’d proposed the following in response to my disquiet over the state of Agile as it moves into the mainstream, so someone suggested I run for chair on a platform of carrying it through. I did, and I was elected. I’ll be chair until August, and I take it as my responsibility to bring some derivative of this to a vote of the membership. We’ll be working on this proposal at the Agile Software Development forum. Help out, please.
(more…)

One of the hard things about teaching people Agile is helping them understand that the product starts out crummy—barely functional, probably looking really crude—and then keeps getting better and better each iteration. That stops when you reach the release date, or when you decide that all the remaining ways you can see to make it better aren’t worth the expense.

Stories, metaphors, declamations—they all help, some, but I think what I need most is a video like one of those time-lapse movies of a flower opening or a butterfly emerging from a chrysalis. I started making one by taking short quicktime snapshots of a product at the end of each iteration, but let it slide.

This last consulting visit, I was working with a product owner, and I realized that the famous 15 minutes to a weblog Rails video is like what I’m looking for. There’s a lot of commentary interesting only to a programmer, and it never does get a flashy UI, but there’s also visible growth.

The rest of the post gives a timeline so that you can skip around.
(more…)

[This is a combination of what I intended to say at XP Day Toronto last weekend and what I did say. Note: After the talk, a couple of people told me that Kent Beck has some videos that make some of the same points. I haven’t looked at them yet.]

[UPDATE: INFOQ has an overview and better link to the Beck videos.]
(more…)

There’s a style of writing about software that’s bugged me for a long time. It’s what I call the “Joe burst into the room” style because it often starts with a sentence something like that. It’s a little morality fable in which a point about software development is made largely through a conversation between pairs of people.

I have two problems with the style:
(more…)

• Can you describe your audience? I used to ask the question in terms of types of reader - manager, tester, team lead, etc. - nowadays I might ask the author to describe a typical reader as a person rather than a role (as a persona, if you will).

• When a reader finishes your article, she should know more. But that’s not enough. Knowledge has to be put into practice. How will she do that? Will she know the first step to take? What, in the first few months after publication, do you want 1000 of your readers to have accomplished?

• When she puts your idea into practice, what beginner mistakes will the reader make?

• In what situations is your advice the wrong advice? When does your favorite tool/method/technique not apply? (”When people aren’t trained well enough” or “when there’s insufficient management support” almost always mean you haven’t thought things through well enough: there must be cases where your pet idea would be bad advice even for the best trained, best supported people.)

• How is your article different than the other hundred articles on the same topic?

See also hints for revising and this extra hint.