Archive for the 'conferences' Category

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

Thanks.

Czech Ruby/Rails conference

I’ve been asked to post a pointer to the first Czech Ruby / Ruby on Rails conference. It would be fun to go, but I surely won’t make it. You can, though.

XP Day Toronto

I’ll be giving the keynote at this year’s XP Day Toronto.

Six Years Later: What the Agile Manifesto Left Out. The Agile Manifesto has worked rather well at changing the way software is built, but the Agile movement is now suffering from some backsliding and some backlash. I believe that’s partly because the Manifesto is almost entirely focused outward: it talks, to the business, about how the development team will interact with it. What it does not talk about is how the team must interact with itself and with the code. In the early days, that didn’t matter so much; the right interactions tended to happen anyway. But now it matters. In this speech, I want to talk in some detail about what got left out.

I’m also co-responsible for the Open Space: What XP Projects Forget:

A successful Agile team is a complicated web of… things: people, practices, tools, and so forth. Some of them are well-documented, some not. Even for those that are documented, Andrew Tannenbaum’s motto applies: “People need more often to be reminded than informed.” As more and more Agile teams form, the need for both reminding and informing is increasing.