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


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]


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]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.




Agile Testing Directions
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects

Permalink to this list


Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list


Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI


Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."


Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich


Where to Find Me

Software Practice Advancement


All of 2006
All of 2005
All of 2004
All of 2003



Agile Alliance Logo