Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Sun, 07 Aug 2005

20

As of today, I've lost 20 pounds. (Naturally, I'm now heading off for New Hampshire, Land of the Giant Ice Cream Cone, for a week of vacation.) It seems to me I need to lose around 10 more pounds of fat and gain back at least 5 pounds of muscle to be in non-pathetic shape. Blogging my weight has definitely helped.

## Posted at 20:28 in category /misc [permalink] [top]

Luck

Somewhere around 1983, I took Ralph Johnson's very first course in object-oriented programming. That led to Ralph becoming my graduate advisor, which led to my being part of his reading group, which led to my reviewing some of Martin Fowler's books in draft, which led to Martin knowing me as a tester guy, which led to him getting me invited to a workshop in Utah, which meant I became an author of the Manifesto for Agile Development, which concentrated my attention on Agile, which is the reason I'm writing this sentence.

It's not just me: even the most talented and virtuous of us need luck. The same is true of fields like Agile. Suppose Kent Beck hadn't met Ward Cunningham? Suppose they hadn't become Smalltalk programmers? (I've talked a little to Ward about Smalltalk's influence on Agile, and one of the things he said was, "Smalltalk people were more offended by software engineering than other people." So they did more about it.) What if Alistair Cockburn hadn't early on gotten the job of surveying projects within IBM to see what really worked? I don't know the whole story of refactoring, but would it have made the big time if Ralph Johnson hadn't been immersed in the Smalltalk world at the same time Bill Opdyke was looking for a dissertation topic?

One of the things I've long taught testers is that they must work to get dumb luck on their side. When filling a database, it's better to make up new names than to reuse the same ones out of habit - even if what you're testing has nothing to do with name-handling code. The more variety in the names you use, the more likely you are to stumble over a name-handling bug.

Moreover, all things being equal, one complicated test that incorporates five test ideas is better at accidentally finding bugs than five simple tests. (This is for after-the-fact testing, note, and all things aren't equal. You have to be aware of the tradeoffs.)

There are a whole bunch of talented people out there poised to learn new Agile ideas and techniques. If we get luck on their side - our side - they'll learn and then teach us. If we don't, some of them will take their talents elsewhere. Others will learn, but what they've learned won't spread.

The Gordon Pask award, I'm now realizing, was partly motivated by that. It's a way of shining a spotlight on people, of saying "Pay attention to these two." That will cause their ideas to spread faster. And, as a public and tangible acknowledgement of accomplishment, it will motivate them to work harder for us.

It has its flaws, though:

• It's only two people, and the pool of deserving talent is much larger. (I especially worry that deserving people will feel slighted and perhaps reduce their efforts.)

• There's no mechanism for rewarding groups, such as user groups. The award shares some of the problems of applying traditional, individual-centric mechanisms of employee evaluation and promotion to Agile teams.

• It's maybe uneasily focused on the potential to become a Big Name. Becoming a big name is not usually merely a matter of invention, discovery, or synthesis; it also requires the ability to explain and to promote. To the extent that we reward all of those things, are we shortchanging what we need most?

• It's a big reward - something like getting tenure. But academics don't just toil away for years and then either get tenure or not. Instead, they proceed incrementally, paper after paper, amassing a cumulative record of smaller rewards (in the form of their Curriculum Vitae). Should there be an equivalent?

• Maybe amplifying the rewards for smaller accomplishments - like experience reports - would produce a better return.

• It's subjective, and that means both bias and the perception of bias are inevitable. The political minefields are many.

I'm still happy about it, but I said we'd be improving it over the next year. What more should be done?

(Thanks to Steve Freeman for conversation about this.)

## Posted at 17:55 in category /conferences [permalink] [top]