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.

Here’s a test for the Cappuccino app I’m working on. It’s about what happens when, for example, you click on “blood collection for transfusion” in the right table here:

- (void)testPutBackAProcedure
{
  [scenario
   previousAction: function() {
      [self procedure: “Betical“
            hasBeenSelectedFrom: [”alpha“, “Betical“, “order“]];
    }
  during: function() {
      [self putBackProcedure: “Betical“];
    }
  behold: function() {
      [self listenersWillReceiveNotification: ProcedureUpdateNews
            containingObject: []];
      [self tablesWillReloadData];
    }
  andSo: function() {
      [self unchosenProcedureTableWillContain: [”alpha“, “Betical“, “order“]];
      [self chosenProcedureTableWillContain: []];
    }
   ];
}

Here’s the code to pass the test (after inlining one method):

- (void)unchooseProcedure: (id) sender
{
  [self moveProcedureAtIndex: [chosenProcedureTable clickedRow]
                        from: chosenProcedures
                          to: unchosenProcedures];

  [NotificationCenter postNotificationName: ProcedureUpdateNews
                                    object: chosenProcedures];
  [chosenProcedureTable reloadData];
  [unchosenProcedureTable reloadData];
}

Did the test clarify my design thinking? No, not really. Will it be useful for regression? I doubt it. Is it good documentation for the app’s UI behavior? No.

Something seems wrong here.

You can get it from the publisher, from Amazon, from Powell’s, from O’Reilly …

The publisher, by the way, says that probably the best marketing for the book is getting reviews up on Amazon.

Cappuccino’s table views aren’t fully finished, so—in version 0.7.1—you can’t just add radio buttons to a table column and have them work. Nevertheless, I wanted something like this:

Since I spent some time figuring out a workaround, I thought I’d save someone some time and write it up.

The workaround used subclasses of CPCheckbox and CPTableColumn. Those were used in the normal way when laying out the window:

  var checkColumn = [[CheckboxTableColumn alloc] initWithIdentifier:@“checks“];
  // …
  var checkButton = [[CritterCheckBox alloc] init];
  [checkButton setTarget: animalController];
  [checkButton setAction: @selector(toggleAnimal:)];
  [checkColumn setDataCell: checkButton]

(nib2cib doesn’t work yet for my application.)

The controller needs to know which checkbox got clicked. I decided to put an index in each checkbox and implement clickedRow on it. (That allowed the action method to ignore whether it was invoked by the checkbox or by selecting a table row, which turns out to be convenient for this application.) The table column’s dataViewForRow: method returns a numbered checkbox. So far, that looks like this:

@implementation CritterCheckBox : CPCheckBox
{
  (CPInteger) index;
}

- (CPInteger) clickedRow
{
  return index;
}

// …
@end

@implementation CheckboxTableColumn : CPTableColumn
{
}

- (id) dataViewForRow: (CPInteger) row
{
  var retval = [[CritterCheckBox alloc] init];
  var target = [[self dataCell] target];
  [retval setTarget: target];
  [retval setAction: [[self dataCell] action]];
  retval.index = row;
  // ..
  return retval;
}

@end

It turns out that CPTableView makes copies of the cells it gets from the CPTableColumn. It uses CPKeyedArchiver/CPKeyedUnarchiver to do that, so those have to be implemented:

@implementation CritterCheckBox : CPCheckBox
//… 

- (void) encodeWithCoder: (CPCoder)aCoder
{
  [super encodeWithCoder:aCoder];
  [aCoder encodeObject: index forKey: @“critter row index“];
}

- (void) initWithCoder: (CPCoder)aCoder
{
  self = [super initWithCoder:aCoder];
  index = [aCoder decodeObjectForKey: @“critter row index“];
  [self setTarget: GlobalCheckboxTarget];   // < <<<<<<<<<<<<<<<<
  return self;
}

@end

The line marked with arrows is a gross hack. CPControls will archive and unarchive actions, but not targets. I decided to fake that by stuffing the target in a global variable and reassigning it on every unarchiving.

When the column is displayed, some of the checkboxes should start off checked. So when a checkbox is created, it asks its target for the appropriate value in the normal tableView:objectValueForTableColumn:row: way:

- (id) dataViewForRow: (CPInteger) row
{
  // …
  checked = [target tableView: nil
                    objectValueForTableColumn: target.checkColumn
                    row: row];
  if (checked) [retval setState: CPOnState];
  return retval;
}

I know a lot of this is stylistically crummy Objective-J. Part of the reason is that I haven’t figured out an Objective-J style yet.

Suggestions about better approaches welcome.

The CheckboxHacks.j source is available on github. So is the whole tree.

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.