Exploration Through Example

I have two ideas for the kind of mini-conferences I’d like to see the Agile Alliance fund.

1. Tests as Communication. I’m not convinced that automated business-facing (acceptance) tests are, in the presence of good programmer testing, all that incredibly useful as tests—as, that is, regression tests, tests that will find bugs created when a programmer changes something here that causes a failure over there. I hope and expect that the programmer tests and exploratory testing would suffice to find enough of those bugs. So the more important purposes of the business-facing tests are (a) to help explain more clearly to the programmer what the product director wants, (b) to give the programmers a tool to structure their work and know when it’s done, (c) to help the product director think through what she wants, and (d) to help people coming upon the project later to understand something about what it’s supposed to do.

   This conference would be about (a), (c), and (d). What makes a test useful as a message from someone today to some later reader? What are the elements of test-writing style?

2. Confessional code. Way back when, I worked on a Lisp virtual machine. I had a policy that no bug would be hard to find the second time. By that, I meant that any time I found a bug hard to diagnose, I’d add code to make the next bug of that sort easy to diagnose. Over time, I produced a system that could answer those two questions parents always fruitlessly ask of children:

   • “All right, who did it?”
   • “What on earth was going through your mind that made you think that was a good idea?”

   The code was confessional, eager to spill its guts.

   In the years since then, I’ve encountered few products so forthright. I think it would be a good thing if more were. I’d like this conference to discuss examples.

These conferences would be run something along the lines of Bret Pettichord’s AWTA and the Kaner/Lawrence/Hendrickson LAWST. In brief: invitation would be based on position papers describing relevant experience or an interesting perspective; presentations would not be timeboxed; presentations would be experience reports; we’d expect the presenter to spend most of her time answering questions about what she did, why it worked (or failed), and in what other situations it might work or fail; and there would be ample time for pair and small group work on the nitty-gritty of actual examples, demos, etc.

As an aspiring internationalist, I’d like to have one conference in North America and one somewhere else (probably Europe).

If you are interested in either of these conferences, please respond in a comment. “Interested” means “I’d gladly give up a weekend to attend this conference” and “I’d willingly pay enough so that the conference could cover modest expenses.”

Thanks.

There’s been some discussion of my proposal to change the Agile Alliance. The proposal will have to be modified, but a lot depends on people’s opinions about the following. Please make your opinion known by voting.

The answer is yes. That’s how I see it.

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.
Read the rest of this entry »

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.
Read the rest of this entry »

[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.]
Read the rest of this entry »