Exploration Through Example

Here are three unresolved debates that many people seem to have agreed to stop having:

• When do Agile teams need to be deftly led in the right direction, and when can managers/leaders/ScrumMasters/those-responsible-for-a-budget just sit back and let them figure it out?

• On the spectrum between intensely-focused specialists and generalists who do everything they do with the same skill, where do we want team members? in what combinations?

• To what extent does Agile require “better” (along some dimension) people?

The tacit, path-of-least-resistance result is not to my taste. In the worst cases I see and hear of, the answers are:

• With the increased emphasis on leadership and greater focus on the executive suite, the tilt is toward guided or nudged teams over “self-organizing” teams.

• What difference does it make? We’ve got the people we’ve got, and we’ll make the best of them.

• Ditto, and however those people improve themselves and along what axes is going to depend on the happenstance thrown up by the day-to-day work.

Perhaps I exaggerate. Early exposure to Norse mythology has made me hypersensitive to centres not holding and that famous quote from Hunter S. Thompson:

We had all the momentum; we were riding the crest of a high and beautiful wave. So now, less than five years later, you can go up on a steep hill in Las Vegas and look West, and with the right kind of eyes you can almost see the high-water mark—the place where the wave finally broke and rolled back.

A large number of the submissions to the Agile2008 Examples stage do not use examples to clarify or explain. As a result, they are too vague to evaluate.

And people wonder why I despair.

Summary: Google and blogorrhoea have turned many conference tutorials into anachronisms. I propose an alternative that’s more like a Lightning Talk session.

I’m reviewing a pile of submissions to Agile2008. (You can too!) I just noticed a pattern in my comments. Tutorials often have this structure:

1. Here’s a problem that needs solving. I have a solution.

2. Here I demonstrate the solution… You now know enough to replicate the solution back home.

3. Wrapup, pros & cons, questions.

What I’ve discovered while reviewing is that I’m much less interested in step 2 than I used to be. For a vast number of problems out there, a quick Google session will find me some tutorials or blog entries or screencasts, each of which probably gives me a poor-to-adequate understanding of a solution. I can fairly quickly dip into them to see if the solution interests me; if it does, I can install the appropriate software, gather all the facts of what would be a dynamite tutorial from the middling-to-poor ones I probably have, and likely find a mailing list to help me when that’s not enough.

That doesn’t work for real cutting-edge approaches, but honestly most of the time I just want to get Capistrano working.

So I find myself recommending something more like lightning talks. The nice thing about lightning talks is that they’re low risk for the listener: if the current talk is boring, the next one is coming in just a few minutes.

So what I want from a non-cutting-edge tutorial is:

1. Here’s a problem. Here are some of its variants. Here are some constraints on a solution.

2. Here I quickly demonstrate what one solution, in action, looks like. Here’s what I think about it. Notice the URL I’m putting at the top-right corner of each slide? Copy it down. That’s my collection of favorite links about all these solutions. It’s the only thing you need to copy from this talk; you get everything else there.

3. Here I quickly demonstrate the next solution…

4. …

5. So that’s where the state of the practice stands. What innovations do I see coming that you should watch for? What do I wish was happening that isn’t?

Note that I’m not saying that all tutorials should be like this. Some things aren’t documented well. Others have to be learned in a group. But, to an increasing extent, a tutorial presenter doesn’t have to be the Person Who Knows, but rather an editor who filters down a flood of possibilities into a few high-relevance ones and tells me a little about each.

I’m test-driving some Rails helpers. A helper is a method that runs in a context full of methods magically provided by Rails. Some of those methods are of the type that’s a classic motivation for mocks or stubs: if you don’t want them to blow up, you have to do some annoying behind-the-scenes setup. (And because Rails does so much magic for you, it can be hard for the novice to have a clue what that setup is for helpers.)

Let’s say I want a helper method named reference_to. Here’s a partial “specification”: it’s to generate a link to one of a Certification's associated users. The text of the link will be the full name of the user and the href will be the path to that user’s page. I found myself writing mocks along these lines:

mock.should_receive(:user_path).once.
     with(:id=>@originator.login).
     and_return("**the right path**")
mock.should_receive(:link_to).once.
     with(@originator.full_name, "**the right path**").
     and_return("**correct-text**")

But then it occurred to me: The structure I’m building is isomorphic to the call trace, so why not replace the real methods with recorders? Like this:

  def user_path(keys)
    "user_path to #{keys.canonicalize}"
  end

  def link_to(*args)
    "link to #{args.canonicalize}"
  end

  def test_a_reference_is_normally_a_link
    assert_equal(link_to(@originator.full_name, user_path(:id => @originator.login)),
                 reference_to(@cert, :originator))
  end

This test determines that:

• the methods called are the right ones to implement the specified behavior. There’s a clear correspondence between the text of the spec (”generate a link to”) and calls I know I made (link_to).

• the methods were called in the right order (or in an order-irrelevant way).

• they were called the right number of times.

• the right arguments were given.

So, even though my fake methods are really stubs, they tell you the same things mocks would in this case. And I think the test is much easier to grok than code with mocks (especially if I aliased assert_equal to assert_behaves_like).

What I’m wondering is how often building a structure to capture the behavior of the thing-under-test will be roughly as confidence-building and design-guiding as mocks. The idea seems pretty obvious (even though it took me forever to think of it), so it’s probably either a bad idea or already widely known. Which?

Alternately, I’m still missing the point of mocks.

P.S. For tests to work, you have to deal with the age-old problems of transient values (like dates or object ids) and indeterminate values (like the order of elements in a printed hash). I’m fortunate in that I’m building HTML snippets out of simple objects, so this seems to suffice:

class Object
  def canonicalize; to_s; end
end

class Array
  def canonicalize
    collect { | e | e.canonicalize }
  end
end

class Hash
  def canonicalize
    to_a.sort_by { | a | a.first.object_id }.canonicalize
  end
end

On the agile-usability mailing list, Jeff Patton wrote something very like this:

One past paper I constantly reference is Lynn Miller’s customer involvement in Agile projects paper, Gerrard Meszaros’ Agile usability paper, and last year’s paper from Heather Williams on the UCD perspective, before and after Agile.

All these are great papers - and I know there’s more.

If he thinks they’re great papers, I do too. I’ve been meaning to read two of them for ages.

The next Naked Agilist tele-conference will be Saturday April 26th 2008 at 8pm GMT.

There’s one of those tagging memes going around. This one is: “grab the nearest book, open to page 123, go down to the 5th sentence, and type up the 3 following sentences.”

My first two books had pictures on p. 123.

The next three (Impro: Improvisation and the Theatre, AppleScript: the Definitive Guide, and Leviathan and the Air-Pump: Hobbes, Boyle, and the Experimental Life) didn’t have anything that was amusing, enlightening, or even comprehensible out of context. So I kept going, which is cheating I suppose. The last, How Designers Think, had this:

The designer’s job is never really done and it is probably always possible to do better. In this sense, designing is quite unlike puzzling. The solver of puzzles such as crosswords or mathematical problems can often recognize a correct answer and knows when the task is complete, but not so the designer.

That’s a hit. It made me realize a flaw in my thinking. You see, it reminded me of one of my early, semi-controversial papers, “Working Effectively With Developers” (referred to by one testing consultant as “the ‘how to suck up to programmers’ paper”). In its second section, “Explaining Your Job”, I explicitly liken programmers to problem solvers:

A legendary programmer would be one who was presented a large and messy problem, where simply understanding the problem required the mastery of a great deal of detail, boiled the problem down to its essential core, eliminated ambiguity, devised some simple operations that would allow the complexity to be isolated and tamed, demonstrated that all the detail could be handled by appropriate combinations of those operations, and produced the working system in a week.

Then I point out that this provides a way for testers to demonstrate value. I show a sample problem, then write:

Now, I’d expect any programmer to quickly solve this puzzle - they’re problem solvers, after all. But the key point is that someone had to create the puzzle before someone else could solve it. And problem creation is a different skill than problem solving.

Therefore, the tester’s role can be likened to the maker of a crossword or a mathematical problem: someone who presents a good, fully fleshed-out problem for the programmer to master and solve:

So what a tester does is help the programmer […] by presenting specific details (in the form of test cases) that otherwise would not come to her attention. Unfortunately, you often present this detail too late (after the code is written), so it reveals problems in the abstractions or their use. But that’s an unfortunate side-effect of putting testers on projects too late, and of the unfortunate notion that testing is all about running tests, rather than about designing them. If the programmer had had the detail earlier, the problems wouldn’t have happened.

Despite this weak 1998 gesture in the rough direction of TDD, I still have a rather waterfall conception of things: tester presents a problem, programmer solves it, we all go home.

But what that’s missing is my 2007 intellectual conception of a project as aiming to be less wrong than yesterday, to get progressively closer to a satisfactory answer that is discovered or refined along the way. In short—going back to the original quote—a conception of the project as a matter of design that’s at every level of detail and involves everyone. That whole-project design is something much trickier than mere puzzle-solving.

I used the word “intellectual” in the previous paragraph because I realize that I’m still rather emotionally attached to the idea of presenting a problem, solving it, and moving on. For example, I think of a test case as a matter of pushing us in a particular direction, only indirectly as a way of uncovering more questions. When I think about how testing+programming works, or about how product director + team conversations work, the learning is something of a side effect. I’m strong on doing the thing, weak on the mechanics of learning (a separate thing from the desire to learn).

That’s not entirely bad—I’m glad of my strong aversion to spending much time talking and re-talking about what we’ll build if we ever get around to building anything, of my preference for doing something and then taking stock once we have more concrete experience—but to the extent that it’s a habit rather than a conscious preference, it’s limiting. I’ll have to watch out for it.

Agile Coach Camp is about creating a network of practitioners who are striving to push the limits in guiding software development teams, while staying true to the values and principles at the core of the Agile movement. We’ve invited practitioners who, like you, are passionate about their work, active in the field and willing to share what they’ve learned.

Do you have a technique or practice worth sharing with your peers? Or an idea you’d like to test out with some leaders in the community? Are you facing challenges and want to get some perspective from other practitioners, or hear how they do things? If you feel you’d benefit from connecting with 80-100 ScrumMasters?, XP Coaches, Trainers, Change Agents and Mentors to talk, draw, argue and explore ideas, then this conference is for you.

You can learn all about AgileCoachCamp on this wiki.

I’m writing my position paper now. I think it will be on avoiding doing whatever things cause the legitimate part of the Post-Agile reaction. (And I do think some parts are definitely legitimate.)

UPDATE: the position paper.

I’m ready for people to take a look at a chapter. It’s actually the second chapter of the book. The introduction, covering prerequisites, the general plan of the book, its goals, what “Cocoa” is, etc.—that will probably be written last.

But to orient yourselves:

• I assume you know Ruby, but nothing about Objective-C, Cocoa, or building apps on the Mac.

• Rather than build the exposition from the outside-in, teaching you first how to draw user interfaces, I’m working from Ruby up. I start with Ruby, start adding Cocoa ideas and tools onto it. The first chapter is very much like that—I’ll let you be the judge of whether it works.

• Especially in the beginning of the book, I want people to start changing code and seeing what happens. Might as well take advantage of Ruby’s fast edit-run loop.

The chapter and associated code are distributed as a disk image.

What am I looking for? Don’t bother with typos, misspellings, grammar, awkwardly-placed figures, and the like: those will all get changed later. I’m interested in two things:

1. Did the approach work for you? Did this chapter flow in a pleasing and sensible way? Is there information inexplicably missing?

2. Where did you get confused or stuck, in either the text or the “try this yourself” sections? Why? What would have helped?

Thanks.

Further announcements will probably go only to the mailing list.

Scott Finney has an interesting comment on my segment of the Naked Agilist podcast:

I listened to the Naked Agilists latest podcast the other day.

Brian Marick’s pitch in particular sparked my interest. He compares agile adoption against Geoffrey Moore’s technology adoption curve and observes a discrepancy; namely the seeming dearth of pragmatists. As I listened, a fundamental question immediately sprung to mind:

- Do we really have a case where the standard curve doesn’t fit, or
- Are we looking at the data incorrectly?

He suspects the latter. He may be right.