Exploration Through Example

There’s a style of writing about software that’s bugged me for a long time. It’s what I call the “Joe burst into the room” style because it often starts with a sentence something like that. It’s a little morality fable in which a point about software development is made largely through a conversation between pairs of people.

I have two problems with the style:
Read the rest of this entry »

• Can you describe your audience? I used to ask the question in terms of types of reader - manager, tester, team lead, etc. - nowadays I might ask the author to describe a typical reader as a person rather than a role (as a persona, if you will).

• When a reader finishes your article, she should know more. But that’s not enough. Knowledge has to be put into practice. How will she do that? Will she know the first step to take? What, in the first few months after publication, do you want 1000 of your readers to have accomplished?

• When she puts your idea into practice, what beginner mistakes will the reader make?

• In what situations is your advice the wrong advice? When does your favorite tool/method/technique not apply? (”When people aren’t trained well enough” or “when there’s insufficient management support” almost always mean you haven’t thought things through well enough: there must be cases where your pet idea would be bad advice even for the best trained, best supported people.)

• How is your article different than the other hundred articles on the same topic?

See also hints for revising and this extra hint.

In the government of this commonwealth, the legislative department shall never exercise the executive and judicial powers or either of them: the executive shall never exercise the legislative and judicial powers, or either of them: the judicial shall never exercise the legislative and executive powers, or either of them: to the end it may be a government of laws and not of men.

John Adams, Massachusetts Constitution (1780)

Read the rest of this entry »

Earlier in the series:
Controller channels

“Omit needless words” is number 13 of Strunk&White’s elementary rules for composing English. It’s a pretty good rule for composing tests, too, but not followed often enough. Let’s rewrite an example of the sort of test I often see.

Read the rest of this entry »

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.