Exploration Through Example

An interesting time-lapse video. Neat to pick out the interactions revealed. Wish they hadn’t sometimes hammed it up for the camera.

On the agile-testing list, I recently made this claim:

I changed the UI of an app and so… I had to rewrite the UI code and the tests/checks of the UI code. It might seem the checks were worthless during the rewrite (and in 1997, I would have thought so). But it turns out that all (or almost all) of those checks contained an idea that needed to be preserved in the new interface. They were reminders of important things to think about, and that (it seemed to me) repaid the cost of rewriting them.

That was a big surprise to me.

Here are more details. Here’s a bit of the current UI:

In this app, you are reserving animals so that professors can demonstrate procedures to medical students (or let the students practice procedures). You put animals and procedures together by clicking on them. In this case, I’ve chosen “Good Morning Sunshine”.

The next thing I might do is pick a procedure, say abdominocentesis. However, there are “business rules” that forbid you from performing that procedure on an animal more than once every two weeks. Suppose Good Morning Sunshine has already been scheduled for abdominocentesis one week before the lab session I’m trying to schedule. In that case, if I clicked “abdominocentesis” (in a list you can’t see), Good Morning Sunshine would disappear from the left (”used”) list. Any other animals excluded by the business rule would disappear from the right (”available”) list.

Fine. Here’s a question: what should happen if I now unchoose abdominocentesis? Good Morning Sunshine is now available - but should she be re-chosen? As it turns out, the desired behavior is for her not to be re-chosen. She’ll appear in the right list, not the left.

Below I show the test that currently describes this. A few words of warning: The UI is written in Objective-J, a language built on top of Javascript. I had to build my own mocking framework for it. Although this test doesn’t use mocks, it’s written using that (idiosyncratic) framework.

The following will be a little easier to read if you know that sut (tester jargon for “system under test”) is the controller that manages the lists. “Withholding objects” is how the rest of the front-end tells the sut which animals are excluded by the current set of chosen procedures. The test first withholds two animals, then withdraws that (by withholding nothing).

- (void) testWithholdingAnNamedObjectDoes_Not_RechooseItIfItReappears
{
 [scenario
 previousAction: function() {
     [sut allPossibleObjects: [betsy, spike, fang]];
     [self simulateChoiceOf: [spike, fang]];
     [sut withholdNamedObjects: [betsy, fang]];
     [self assert: [] equals: [sut.available content]];
     [self assert: [spike] equals: [sut.used content]];
   }
 testAction: function() {
     [sut withholdNamedObjects: []];
   }
 andSo: function() {
     [self assert: [betsy, fang] equals: [sut.available content]];
     [self assert: [spike] equals: [sut.used content]];
   }];
}

But when I first started thinking about this issue, I wasn’t using a click-to-move style. Instead, you dragged from one list to another (and the lists were together in one panel, instead of being split among two). The earlier test for that behavior was, however, almost the same. There’s one changed method, I’d apparently done a global search-and-replace on animal names, and in the earlier version I hadn’t generalized this behavior to apply to procedures as well as animals:

- (void) testWithholdingAnAnimalDoes_Not_RechooseItIfItReappears
{
 [scenario
 previousAction: function() {
     [sut beginUsing: [betty, dave, fred]];
     [self simulateChoiceOf: [dave, fred]];
     [sut withholdAnimals: [betty, fred]];
     [self assert: [] equals: [sut.available content]];
     [self assert: [dave] equals: [sut.used content]];
   }
 testAction: function() {
     [sut withholdAnimals: []];
   }
 andSo: function() {
     [self assert: [betty, fred] equals: [sut.available content]];
     [self assert: [dave] equals: [sut.used content]];
   }];
}

The important thing here is that the “user experience concept” is the same. In fact, that concept even predates this test. In an earlier UI, there weren’t two lists. Instead, each animal had a checkbox next to it. You chose and unchose animals by clicking the checkbox. (Unavailable animals disappeared, just as they do now.)

I’ve reached back in the version control history for that behavior’s test. It’s cruder, because I was still passing strings and dictionaries around. (It was only later that the app grew model objects.) Nevertheless, the structure and intent are the same. In this sense, the test represents a “frozen decision” that’s survived the life of the project (so far).

- (void) testWithholdingAnAnimalErasesItsCheckmarkIfItReappears
{
 [scenario
 previousAction: function() {
     [sut beginUsingAnimals: [”alpha“,  “delta“, “betty“]
                withKindMap: {”alpha“:”akind“, “delta“:”dkind“, “betty“:”bkind“}];

     [self alreadySelected: [”betty“, “delta“]];
     [sut withholdAnimals: [’betty‘]];
     [self animalTableWillContainNames: [”alpha (akind)“, “delta (dkind)“]];
     [self animalTableWillHaveCorrespondingChecks: [NO, YES]];
   }
 testAction: function() {
     [sut withholdAnimals: []];
   }
 andSo: function() {
     [self animalTableWillContainNames: [”alpha (akind)“, “betty (bkind)“, “delta (dkind)“]];
      [self animalTableWillHaveCorrespondingChecks: [NO, NO, YES]];
   }];
}

Some people, including Alexey Krivitsky and Declan Whelan, have been talking about an #agilecoachtour. When I heard of it, I thought of the Festival Express train trip, jam session, and concerts.

I’ve also long been thinking about a talk Alistair Cockburn gave a zillion years ago about how high-performance individuals are good at a large number of “micro-techniques”. It’s not [just] brainpower or hedgehog-style great ideas: it’s excess skill at a vast number of tricks of the trade. Someone (Jeffrey Fredrick?) was telling me it’s something like that for elite swimmers: you learn to do many things better than the competition, even though none of them is in itself more than a slight improvement.

I also have an increasing desire for speakers to speak about what newly excites them, rather than reiterate their safe, well-worn conclusions. Related to that: I’d like to see speakers more directly serve their audience. (For example, for my Ágiles 2009 keynote, I’m asking the audience to tell me—in advance—the questions and topics they’d like me to speak on.) But I don’t much care for straight question-and-answer sessions, since those don’t “build” to a conclusion and tend not to surface much novelty.

So here are some vague thoughts:

• The structure of the trip would be long train rides, including overnight travel, that allow the riders to work/jam together. When the trip stops in a city, it’d be for a one-day conference.

• People would work together actively to learn things they’d present at one of the stops. So, for example, I might present “Thoughts on Mocks collected by talking and working with Freeman, Feathers, etc.” And many of the thoughts would not be of the form “The difference between mocks and stubs is…” but things like “when using mocks to TDD a UI, have mock objects just accept setters and return values with getters, which makes for more concise tests.”¹

• I’ve favor one-on-one work over group discussions. Two people talking or working together are more likely to get down-and-dirty than a group. (That’s part of the appeal of a train—it favors micro-groups.) I can see a person pursuing a particular topic working in a series of “sequentially monogamous” relationships.

• I can also imagine “customers”—non-coaches with problems—joining the trip for a day or so to serve as audience proxies to champion particular topics and shepherd creation of something useful. (This is maybe a little like my idea for an AR⊗TA conference.)

¹ That’s not actually an idea I got from either of those people, so don’t blame them. It’s just that I’ve been noticing that this test:

     [sut disappear];

     [self assertTrue: [sut.pageView hidden]];

is clearer than a version that’s explicit about expectations:

   during: function() {
     [sut disappear];
   }
   expect: function() {
     [sut.pageView shouldReceive: @selector(setHidden) with: YES];
   }];

And it’s not just the whacky syntax in the latter. It has more to do that a GUI framework (at least Cocoa and its Javascript version) tends to have GUI objects that rely heavily on setters and getters. Maybe you would follow tell-not-ask when designing your own framework, but the people who designed those didn’t. So deal.

I did talk with Steve Freeman about it last week, and at least he didn’t recoil in horror.

My final word at the NSF workshop:

A Plug for Natural History
in the style of
Darwin’s Living Cirripedia (in 2 volumes!)

1. Ever since the TRW studies, Software Engineering has been primarily the Software Engineering of the large corporation. I maintain that many small businesses operating within platform ecosystems develop software differently than large enterprises, and that the differences are both important and interesting.

2. Many researchers think they understand Agile but - through no fault of their own - do not. (It’s like this: you can have read books, you can have read about writing books, you can have written articles - nevertheless, writing a book well is a different thing than writing an article.)

To put someone else’s time where my mouth is: Dave Hoover of Obtiva has volunteered to host researchers who’d like to visit. I can even imagine some more ambitious get-together that bridges the gap I see.

Result: Except for RPG, no interest yet.

Here’s an example of what I meant by my earlier position. Suppose I were a professor and someone wanted to do a PhD under me. He or she is sort of interested in databases, sort of interested in software engineering, sort of interested in whatever I can come up with. I would say something like this:

“There was a NoSQL workshop recently. People who developed non-relational databases (mostly because of scaling issues) got together to talk. Over the next few years, I expect you to become the academic expert on the, uh, ‘totality’ of that sort of database. That means things like these:

“You’re going to need to describe the databases with the same care and precision that Charles Darwin used to describe barnacles. That would include the obvious, like some sort of taxonomy for them—preferably one that you discover in the wild rather than bring to it. Here’s a wild idea: there’s a style of research they use in the social sciences for that, grounded theory. (Take a look at Angela Martin’s dissertation and what Robert Biddle’s students do.) You’ll have to figure out how to apply it to non-humans.

“But more than that, I want you to write some superb user documentation for at least one of the databases (pick the one that needs it most). I think writing about how to use something gives you great insight into that thing. You’re also contributing back to the world that’s giving you something to study, and the taxpayers who are paying part of both of our salaries.

“Now, before you can write superb user documentation, you have to use the thing being documented. You should become a better-than-just-competent user of at least several of these.

“I also want you to learn the internals, both from a design point of view and also from a nitty-gritty point of view. So you should become a committer on at least one of the open source projects.

“I also want you to travel and work at places that use the databases. Part of your research will be on how such databases have disrupted (or just changed) both normal development processes and also the systems being built. I can imagine you going to four kinds of places:

• “Places that are switching an existing app to the new-style database.

• “Places that are starting out with a new-style database.

• “Places that have been using the new technology for a while.

• “The places that first wrote one of the new databases.

“At the end of all that, I want you to be able to say something wise or at least suggestive about the introduction of disruptive technology.

“Since you’re going to be an expert on at least one of the databases, we can get companies to pay to have you visit (in at least the first two cases and—I bet—in the third). We’ll see if we can scrounge up grant money for the fourth kind, but you may have to do a Corey-Haines-style tour.

“That’s a start. I expect we’ll think of more things that push you toward learning everything there is to know about a particular part of the world, from every sensible angle.”

I got invited to a National Science Foundation workshop whose…

goal broadly speaking will be to reflect on software
engineering research and practice of the past, to determine some areas
in which “rethinking” is needed, and to engage in some rethinking.

I have a position (strongly held, of course). But when I look at the list of attendees and their affiliations, I worry that I may be the only person there representing, well, you: the kind of person who reads this blog or (especially) follows me on twitter. So I’d like to hear what you think needs rethinking. (Please include a tiny bit about what kind of person you are. Something like “rails developer in boutique shop”.) You can reply here, via email, or by responding to my tweet on the subject.

My basic position goes something like this:

Twenty years ago, the self-conception of the software engineering researcher went something like this, I think:

I am a scientist, though partly of the applied sort, discovering important principles which engineers will then put into practice when building systems. I aspire to be something like the Charles Darwin of The Origin

I think the world has moved on from that. What was once an intellectual structure that could be considered built has since exploded into something more like a genuine ecosystem. There are vast numbers of people, communicating in all kinds of strange ways, assembling practically innumerable pieces of software in scrapheap ways, collaborating—quite often across organizational boundaries—in a way more reminiscent of a rhizome than a command-and-control tree.

The appropriate response to that is to go back in time before The Origin to the Charles Darwin who spent eight years studying barnacles, grasping their differences, and publishing the definitive work on them. There is a lot to study in the software development ecosystem (which, note especially, will require collaboration with researchers who know more about people and groups than context-free grammars).

Time to switch from Alan Kay’s glamorous “the way to predict the future is to create it” to something more in keeping with Kuhn’s normal science: the world is out there; mine it for deep knowledge and extensive data (against, I hope, the background of the “paradigms” used by practitioners).

Part of a series on the seven pillars of a good Agile team

In the world of software, there are two competing slogans:

• “Many heads are better than one.”
• “A committee is the only form of life with many heads and no brain.”

In a skilled Agile team, the first slogan wins. It is routine for two or more people to do better work together than any of them could do alone.

Some evidence of collaboration

• Pair programming.

• People frequently wave over other people to ask them questions or to seek help. Especially significant are “cross-disciplinary” conversations where a programmer waves over a tester or a user experience designer waves over a programmer.

• People frequently go to the product owner to ask small questions, rather than bunching questions up into marathon sessions.

• The code isn’t divided into subsystems that “belong” to someone and that other people dare not change.

• There are “big visible charts” or “information radiators” that everyone can easily see, that track data of interest to the team, and that actually get updated on time.

• “The best person for the task” will sometimes not do it—at least not alone. People are accustomed to reaching out past their own specialty.

• The words “That’s none of your business” are neither spoken nor implied. The team errs on the side of visibility.

Earlier this month, I gave a talk at Agile Roots on Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism. It was well-received. They’ve now released the video. The talk is about 25 minutes long.

Artisanal Retro-futurism crossed with Team-scale Anarcho-syndicalism seems a hit. I made upward of 400 stickers, and I have only a handful left. There’s been talk on Twitter about other types of Agile conferences, so let me make a rough proposal for a conference that focuses on solidarity and syndicalism and self-help.

There would be four parts to the conference.

• Chronologically first would be presentations from teams (or team representatives) on problems they’re having adopting Agile. The presentations would be in the LAWST structured-conversation style, or something like it. The goal of each conversation would be to give the team ideas about what to do next and how to do it.

  Teams would have to apply in advance to get their problems discussed. They’d also be expected to later provide a case report (or interviews for a case report) on what worked or didn’t.

  Perhaps toward the end of the conference, we should expect recipients of advice to give something like a lightning talk explaining which advice they’ll be taking.

  A semi-related idea: perhaps participation here is a prerequisite for a visit by the ScrumMaster of Last Resort?

• The second set of presentations would be from teams who’re doing well enough but are nevertheless eager to do better. As an “entry fee”, these teams would have to participate in the first sessions (helping people who’re having trouble getting properly started). The format would be the same.

• In the third sequential session, the scope expands to what can we do about the sorry state of things in general—how can we help all those other teams that aren’t at the conference?

• Throughout, there’ll be short demos or lightning talks about Gosh Wow neat things people have tried. (Too much problem-solving can be depressing, so let’s celebrate the neat and the new in true Retro-Futurist style.)

I was asked for more details about the pillar-based retrospectives I mentioned earlier.

Preparation

Have scrap paper or notecards, plus writing instruments.

Execution

The team assembles and sits. They get some paper.

I let a random person pick which pillar to start with. I describe it to them, then tell them to individually rate the whole team against it, on a one-to-five scale, five being the best, then write their rating on some paper. I tell them they can pick a range if they’re not sure which number to pick. (I think that’s what numbers like “3.5″ often mean.)

(In the future, I’ll have the team come to some consensus about what they mean by “one” and “five”. Some people, for example, consider “five” perfection and thus unattainable.)

When they’re ready, they hand the paper to me. While that does make it less obvious which person wrote which number, that’s a minor motivation. I do it more because it gives each person control over how long to think.

Then I plot the values on the spider chart, like this:

Then I invite the team to discuss whatever the spread or values bring to mind. If I see something no one mentions, I bring it up, but the discussion is really in their hands. Their talk may lead to action items, but I don’t force it.

After the discussion of one pillar dies down, I have someone pick the next one. (I think that each time we soon just started going clockwise or anti-clockwise.)

It seems like these retrospectives want to be about an hour long.