Exploration Through Example

I’m reading a draft of Jim Shore and Shane Warden’s Art of Agile Development. So far, it’s fantastic, packed full of juicy tricks of the trade. I’ll be giving a copy to every team I work with, I’m sure.

Steve Hayes writes that Scripting for Testers “has the clearest explanation of regular expressions that I’ve come across.” Assuming it’s not the only explanation he’s read, I’m immensely pleased. I think regular expressions are terribly important for my intended audience*, and I was worried my explanation wasn’t good enough.

* As I write, I’m wearing my regular expression T-shirt:

Which Programming Language are You?

Guess it’s time to start that Erlang book.

P.S. My daughter:

After the Javascript-is-really-Scheme-sort-of workshop at SPA, I’m pleased.

I find myself advising new Agile teams to go slower than they could. Here’s the thing: at the beginning, they’re probably working on a bad code base, and they have yet to learn important rules and habits. They will find it easy to go faster than is compatible with making the code more malleable.

They are nevertheless likely to delight the business, because it’s getting actual observable features at a steady pace. They’ve also established a velocity. As they learn more, they will find their velocity needs to decrease. From the inside, a decreasing velocity is part of a necessary improvement. From the outside, it looks like things are going wrong. Pressure arrives, even if only pressure generated internally by the team. They may therefore not slow down enough, which is buying trouble for the long term. That looks like this:

My preference is to go slower at first, but always fast enough to keep the business happy. That’s often pretty easy, as they have such low expectations. With a tolerant business and an appropriate velocity, you have nowhere to go but up. You can improve your skills, your code, and your velocity all at once. Like this:

Now, a bird in the hand is worth two in the bush, a euro today is worth more than a euro tomorrow, and a rational actor might be justified in preferring the first curve to the second. However, the novice teams I coach are in places that have already paid the price for going too fast, so that argument probably does not apply.

Because people are not rational actors and are acting in a world of radically imperfect information, we have to be careful. Because the business will structurally err on the side of wanting the team to go too fast, the team must err on the side of going too slow. In order for slowness to be tolerated, they must have an even more relentless focus on the business value and product-director-pleasingness of the velocity points being delivered. It may also require some mule-like intransigence. (Someone—Schwaber, maybe—once told me that one of the advantages of Scrum is that it has rules. When, for example, a executive wants to take aside a programmer for a special project, the Scrum Master can depersonalize the conflict by saying that The Rules say that means blowing the sprint, and does he really want to do that? It’s a shame the code internals have no such protection.)

We don’t need post-agile. We need pre-agile. More later.

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.

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.
(more…)

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