Exploration Through Example

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.

I am going to write a document called “The Mechanics of Business-Facing Automated Tests”. I’ll be posting drafts of the different chunks here, hoping that you’ll help me improve it. I’m interested in improvements to the ideas and the flow of explanation rather than line-by-line or word-by-word improvements. Thanks.

The sample application is only a realistic sketch. It pretends to be the server part of a system used by travel agents. For my own convenience, I wrote the application in Ruby, but I’m treating it just as I would were it in Java. The tests are written in Ruby for the reasons I gave earlier.

In normal use, the application is a server that communicates with a client and with airline servers. The server communicates to the client via XML messages over a network. To communicate with airline servers, it drops files on disk to be picked up by FTP. Airline servers deliver files in the same way.
Read the rest of this entry »

I’m not the only person thinking of writing Fit-like tests in Ruby. Zenspider had the same idea first.

Via xkcd, publication here permitted by a Creative Commons Attribution-NonCommercial 2.5 License

Jeff Overbey has an extensive list of papers about things computer scientists consider harmful. With links, in many cases.

Elisabeth Hendrickson has a nice cheat sheet that will help you get ideas for tests.

That title seems like a good motto in general. Here’s a specific instance.

I was on a short consulting trip recently. We talked about Fit. I said the two things that I’ve said to clients at least ten times:

“I recommend using Fit when the product director wants to read the tests or when the data is naturally tabular. If the product director doesn’t care or if the test is a do-this-do-that-check-this type test, I’d rather you used xUnit.”

…

“There are no decent HTML editors. The most tolerable I’ve found is OpenOffice, but they’re all a pain when you want to modify tables.”

There’s a contradiction here. If the product director doesn’t care, why would you write a tabular test in HTML? Because using xUnit means you have to keep columns aligned, and that’s a pain. So use HTML and have the browser line up the columns. But I just said that editing HTML is also a pain. And I never gave much thought to which is the greater pain.

Read the rest of this entry »

This is a retitled version of my SPA 2007 talk, “Monasticism for the Married”. It’s an encouragement to think of things as bundles of actions, framed by some alarm about the state of Agile.

Clearly reason was the goal here, and with Mark and Grace calmly looking on, it struck me just how good men are at agreeing exactly what “reason” is, how it should be pursued, and at what cost achieved.

—Thomas H. Cook, The Cloud of Unknowing

I’m intensely aware that at this time tomorrow, you’ll be hearing from Sir Tony Hoare, one of my heroes when I first got into this field. When I noticed him on the programme, I reread his 1980 Turing Award lecture, which contains this famous quote:

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

When I was young I wanted nothing more than to pursue that first way, but looking back I see that I haven’t. In such a case, the only honorable thing to do is to blame someone else:

Read the rest of this entry »

This is an example of a WordPress page, you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress.