Archive for October, 2007

I’m looking at you, Keynote

When the hell are personal computer software makers going to let us recover from crashes as well as Emacs has done for well over twenty years? Most of a day’s work lost, and it is not my fault, because it’s not my job to develop the right reflexes for your stupid program!


At the functional testing tools workshop, Ward Cunningham devised a scheme. John Dunham, Adam Geras, Naresh Jain, and I elaborated on it. Before I explain the scheme, I have to reveal the context, which is different kinds of tests with different audiences and affordances:

text flowing into text

This is your ordinary xUnit or scripted test. The test is at the top, the program’s in the middle, and the results are at the bottom. In this case, the test has failed, which is why the results are red.

The scribbly lines for both test and results indicate that they’re written in a language hateful to a non-technician (like a product owner or end user). But you’d never expect to show such a person failing results, so who cares?

a textual test produces a binary indication of success

Here’s the same test, passing. The output is just a binary signal (perhaps a green bar in an IDE, perhaps a printed period from an xUnit TextRunner). A product owner shouldn’t care what it looks like. If she trusts you, she’ll believe you when you say all the tests pass. If she doesn’t, why should she believe a little green bar?

A Fit test

Here’s a representation of a Fit test. Both the input and output are in a form pleasing to a non-technician. But, really, having the pleasant-looking results isn’t worth much. It makes for a good demo when showing off the tool, but does a product owner really care to see output that’s the input colored green? It conveys no more information than a green bar and depends on trust in exactly the same way. (James Shore made this point well at the workshop.)

A graphical test fails with text

Here’s one of my graphical tests. The input is in a form pleasing to a non-technician. In this case, the test is failing. The output is the same sort of gobbledegook you get from xUnit (because the test is run by xUnit). Again, the non-technician would never see it.

A passing graphical test gives one bit of information

Here’s the same test, passing. My test framework doesn’t make pretty results, because I don’t think they have value worth the trouble.

A swimlane test passes the same as any textual test

Here is one of Ward’s “swimlane” tests. The test input (written in PHP) would be unappealing to non-technicians, but they never see it. This test fails, and so it produces nothing a non-technician would want to see.

A passing swimlane test is browseable

Here’s the passing test. The output is a graphical representation of how the program just executed. It is both understandable (after some explanation) and explorable (because there are links you can click that take you to other interesting places behind the curtain.)

As when I first encountered wikis, I missed the point of Ward’s newest thing. I didn’t think swimlane tests had anything to do with what I’m interested in: the use of tests and examples as tools for thinking about a piece of what the product owner wants with results that help the programmers. With swimlane tests, the product owner is going to be mostly reactive, saying “these test results are not what I had in mind”.

What I missed is that Ward’s focus wasn’t on driving programming but on making the system more visible to its users. They were written for the Eclipse Foundation. It wants to be maximally transparent, and the swimlane tests are documentation to help the users understand how the Foundation’s process works along with assurance that it really does work as documented.

What Ward noticed is that his output might fit together nicely with my input. Like this:

A cycle of understanding

Here, the product owner begins with an executable graphical example of what she wants. The programmers produce code from it. As a user runs that code, she can at any moment get a bundle of pictures that she can point at during a conversation with the producer and other users. That might lead to some new driving examples .

The point of all of this? It’s a socio-technical trick that might entice users to collaborate in application development the way wikis entice readers to collaborate in the creation of, say, an encyclopedia. It’s a way to make it easier for markets to really be conversations. John Dunham dubbed this “crowdware”.

It won’t be quite as smooth as editing a wiki. First, as Naresh pointed out, the users will be pointing at pictures of a tool in use, and they will likely talk about the product at that level of detail. To produce useful driving examples (and software!), talk will have to be shifted to a discussion of activities to be performed and even goals to be accomplished. The history of software design has shown that we humans aren’t fantastically good at that. Adding more unskilled people to the mix just seems like a recipe for disasterware.

Wikis seemed crazy too, though, so what the heck.

Laurent Bossavit and I are working on a site. Once it reaches the minimal features release, I’ll add some crowdware features.

Power steering or no?

I realized at the functional test workshop that, to some extent, the six years of Agile have replaced development teams whining about incomplete requirements with development teams whining about the lack of a product owner’s time.

Really: is that progress?

Well, yes. At least we’re not still whining about changing requirements.

Nevertheless, this flash made me think about that old XP metaphor of the Customer driving the project like a person driving a car. When you drive, you don’t think about the steering wheel, you simply think about turning the car, and it turns. The steering wheel, the philosopher Heidegger said, is ready-to-hand. But when the power steering goes out, suddenly the steering wheel is in your face. What was once a simple reflex is now a conscious act. The steering is present-to-hand.

A tool being present-to-hand can be good or bad, but it’s always disconcerting.

Think of it: to the product owner, the team is always present-to-hand. She must attend to them. It’s not like driving at all.

Directing a product team must be something like my telling my 12-year-old to clean his room. When I do that, he goes off, comes back, and reports that he’s done. When I look at his room, I see 18 different things that are still lying on the floor. I have to painstakingly tell him 18 different things to pick up. Were it not for my steely determination to raise presentable human beings, I’d just do it myself.

That feeling is what it must be like to be a product owner.

A Little Ruby

I got a nice note today complimenting me on my never-finished A Little Ruby, a Lot of Objects. I get those every once in a while. It’s a Ruby book modeled after The Little Lisper.

I’ve been considering what to do with this, my second midlife crisis. (The first was at 28.) Having bought the Porsche, gotten fit, and gotten divorced in the first one, the customary responses are out. Been there, done that. So, instead, I’ve been thinking that finishing A Little Ruby might be a good use of pent-up frustration and legacy idealism.

Besides being fodder for language geeks, it would also have a practical purpose: I think of it as becoming the best book for those wanting a gentle introduction to extreme metaclass hackery.

Also: having just gotten a royalty check for Everyday Scripting, the idea of publishing the results appeals.

Would you buy such a book? Do you think other people would?

Ruby hackery needed

Here’s a kind of code I find myself habitually writing until I realize I can’t implement it:

    watch {
      # some calculation
    }.and_whenever(:something_happened) {
      # do something
    }.and_whenever(:something_else_happened) {
      # do something else

What I want this to do is:

  • Stash away the block with “some calculation”

  • Run the second block. This does something that will affect the calculation.

  • Run the third block. This does something else that will affect the calculation.

  • Run the first block, then undo the effects of the following blocks.

The problem is that I don’t see a way to know when you’ve reached the end of the chain of 2nd, 3rd, … blocks, and it’s now time to execute the first block.

Now, there are alternatives. You can put the blocks in the right order. You can make a single and_whenever that takes a hash from names to lambdas as its single argument (presuming the order of evaluation doesn’t matter). You can put a “sentinel” method at the end of the chain, like .ok_do_it_now.

What I’m wondering if there’s some clever way of making the original form work.

Mailing lists for gems

I’ve created both “announce” and “discuss” mailing lists for my different gems:

gossip 0.3.2

I just committed a change to a project Laurent Bossavit and I are working on. As a result of that, the following happened:

  1. This came via Jabber:
    A Jabber message
  2. This was posted to Twitter:
    A twitter post
  3. This came in email:
    A mail message
  4. This was sent to Campfire:
    a chatroom message

Had I deployed a new version, I would have gotten deployment messages to each of the above, plus in our Trac timeline:

Trac timeline

(Trac does a perfectly fine job of handling commits on its own.)

That’s all due to a library of mine called Gossip, which provides a unified interface to all those destinations. It comes with three utility scripts:

  • svntell, which you’ve seen.

  • watchdog, which reports on the output and duration of a command. (It’s derived from the script in Part 4 of Everyday Scripting with Ruby.)

  • fanout, a command that relays a message to the distant destinations. (Our Vlad task uses it to report on deployments.)

The commands and library use the User-Choices library, so they’re configurable up the wazoo.

All this: done in service of ease at work.

I hope you use it.

More mock test samples

Here are two more examples of what might become my style for writing tests that use mocks. They add a “because” clause that separates what comes into the mock from what comes out of it.

  def test_checker_checks_again_after_grace_period_in_case_of_error 
    checker = testable_checker(:grace_period => 32.minutes) 
    during { 
    }.behold! { 
      and_then @timesink.will_receive(:sleep_for).with(32.minutes) 
      and_then @network.will_receive(:ok?).with(”url”) 
      but @listener.will_not_receive(:inform) 
    }.because { 
      but_then @network.returned(true).from(:ok?) 

As before, the test first describes the activity of interest in a “during” clause. The point of the test is how the object poked in the “during” clause pokes the rest of the system. That’s in the “behold!” clause. The next question is the connection between the two: why did the object do what it did? There’s a good chance you know why from the name of the test and from reading previous tests (which I tend to arrange in a tutorial sequence). If not, you can dive into the “because” clause, which details how the rest of the system responded to the poking.

  def test_checker_finally_tells_the_listener 
    checker = testable_checker 
    during { 
    }.behold! { 
      @listener.will_receive(:inform).with(/url is down/) 
    }.because { 
      and_then @network.returned(false).from(:ok?) 

Let us now praise famous men

Steve’s right - this slideshow of what people are uploading to Blogger is oddly fascinating.