Archive for June, 2007

Two conference ideas

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.”


Some preliminary voting

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.

A first fork in the decision tree seems to be the answer to this question:

RESOLVED: The Agile Alliance should explicitly focus on helping members of Agile teams succeed, leaving concern with the larger organization to others.

“Members of the Agile team” is defined to be everyone who’d be expected to attend a team standup meeting: programmers, testers, user experience designers, Scrum product owners or XP Customers, technical writers, and so on.

Pro or con?

Put differently, Mike Feathers asked:

the way you’ve been discussing the AA, it seems like you see it primarily as an organization for developers, testers, and analysts/customers.. the people who are front line in development. Is that the case?

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