The Walking Skeleton

I pick what I think will be a good “walking skeleton” feature, a feature chosen specifically to quickly conjure much of the application structure into existence. I choose this feature: On launch, Towers displays an 8 block x 8 block “city” of black and white towers, each one floor high, arranged in a checkerboard pattern.

With this feature in mind, I write the first acceptance test.

The City is Eight Blocks Square

Acceptance test: The city is eight blocks square. I try to make the test very expressive, using a “fluent” style of assertions. To support the test, I write a CityFixture class to access information about the city through the GUI, and a CityAssertion class to build the fluent assertion DSL. (This may seem overly complex to you. Hold that thought.)

For assertions I use the FEST Fluent Assertions Module. I like the fluent style assertions. In particular, I like being able to type a dot after assertThat(someObject), and having Eclipse pop up a list of things I can assert about the object.

To sense and wiggle stuff through the GUI, I use the FEST Swing Module.

Implementation. To pass this test, I write code directly into Towers, the application’s main class.

At this point, Towers has a display (an empty JFrame), which is prepared to display 64 somethings in an 8 x 8 grid. But it doesn’t yet display any somethings. It’s an 8 x 8 ghost city.

Each City Block Has a One Floor Tower

Acceptance test: Each city block has a one floor tower. To extend the test DSL, I add TowerFixture and TowerAssertion classes. (This DSL stuff may now seem even more complex to you. Hold that thought.)

Implementation. I make the main class display a JButton to represent a tower at each grid location. Grid location seems like a coherent, meaningful concept, so I test-drive a class to represent that. I quickly find that I care only about the location’s name, so I name the class Address. I name each button based on its address, to allow the test fixtures to look up each “tower” by name. Each button displays “1” to represent the height of the tower.

At this point, there is no model code beyond Address. A tower is represented only by the text displayed in a button.

Speculation. To pass this test I could have used a simple JLabel to display the tower height. My choice of the more complex JButton was entirely speculative. That was very naughty.

More speculation. I notice that there’s an orphan Tower class sitting all alone in the corner of the repo. Though I’m trying to code outside-in here, my natural bias toward coding inside-out must have asserted itself. The class isn’t actually used in my app, which suggests that I wrote it on speculation. It’s interesting that I would do that. I wonder: Is all inside-out coding speculative?

Blind speculation. I didn’t commit a test for the unused Tower class. I’m sure that means I didn’t write one. So I must have coded it not only speculatively, but blindly. Eeep!

Repospectives. As I step through the commit chain, I see my sins laid out before me. If Saint Peter uses git, I’m fucked. But I wonder: What else might we learn by stepping through our own git repositories?

Towers Alternate Colors

Acceptance Test: Towers alternate colors. I express this by checking that towers alternate colors down the first column, and that towers alternate colors along each row.

Simplifying the fixtures. As I write the third test and the fixture code to support it, I become weary of maintaining and extending my lovely DSL. I abandon it in favor of writing indicative mood statements in simpler <object>.<condition>() format. Now I need only one fixture class per domain concept, rather than two (a class to access items through the GUI and class to make assertions).

Though “the city has width eight” doesn’t trip off the tongue as nicely as “the city is eight blocks wide,” it conveys nearly the same information. The only loss is the idea of “blocks.” I’m okay with that.

Implementation. I make the main class render each button with foreground and background colors based on the button’s location in the grid.

Adding features to the main class. At this early point in the project I’m implementing features mostly by writing code directly in the main class. I’m nervous about this, but I’m doing it on purpose, deliberately following the style Steve Freeman and Nat Pryce illustrate in Growing Object-Oriented Software, Guided by Tests (GOOS). For early features, they write the code in the main class. Later, as the code begins to take shape, they notice the coherent concepts emerging in the code, and extract classes to represent those.

When I first read that, I was surprised. My style is to ask, before writing even the smallest chunk of code: To what class will I allocate this responsibility? Then I test-drive that class. Steve and Nat’s style felt wrong somehow. I made note of that.

Around the same time that I first read GOOS, I watched Kent Beck’s illuminating video series about TDD. In those videos, Kent often commented that he was leaving some slight awkwardness in the code until he had a better idea became apparent (I’m paraphrasing from memory here, perhaps egregiously).

So once again a pattern emerges: Someone really smart says something clearly nonsensical. I think, “That makes no sense,” and let it go. Then someone else really smart says something similar. I think, “How the hell does that work?” Eventually, when enough really smart people have said the same stupid thing, I think, “That makes no sense. I’d better try it.” Then I try it, and it makes sense. Immediately thereafter I wonder why it isn’t obvious to everyone.

As I’ve mentioned, my bias is to code inside-out, writing model code first, then connecting it to the outside world. Now aware of my bias, I chose to work against it. I wrote the code directly into the main class. I was still nervous about that. But I’m still alive, so I must have survived it.

Commit. The first feature finally fully functions. As I commit this code, a tower is still represented only by the color, text, and name of a button. The only model class is Address, a value class with a name tag.

This will change in the next episode when, within seconds of committing this code, I somewhat appease my I MUST ALWAYS ADD CODE IN THE RIGHT PLACE fetish by immediately extracting a new class.

That Skeleton Won’t Walk

There’s a problem here. Though I’ve implemented the entire walking skeleton feature, and the implementation brings major chunks of the user interface into existence, the feature does not yet compel the system to respond to any events. It therefore does not require the system to do anything or decide anything in response to external events.

In retrospect, I chose a poor candidate for a walking skeleton. For one thing, it doesn’t walk. It just sort of reclines. For another, it’s not a whole skeleton. At best it’s a ribcage. A reclining ribcage. So there’s a lesson for me to learn: Choose a walking skeleton that responds to external events.

As I wrote this blog post, I searched the web for a definition of “walking skeleton.” Alistair Cockburn defines a walking skeleton as “a tiny implementation of the system that performs a small end-to-end function.” If I’d looked that up earlier (or if I’d remembered the definition from when I first saw it years ago), I would likely have chosen a different feature to animate this corpse. Likely something about moving one tower onto another.

My goal was to code the first few basic features of the game myself, such as moving one tower onto another. And I would include some smelly code for participants to refactor. Over the course of the workshop, participants would write additional features—determining which moves are legal, detecting the end of the game, and so on.

That was my intention.

I started writing the code, and worked on it in rare spare moments over the last eight months. As of a few weeks ago, I’d gotten the code as complete as I needed for my workshops, and was spinning my wheels, dabbling in various refactorings for my own amusement.

GOOS. As I was spinning, a conversation suddenly blossomed in the Growing Object-Oriented Software (GOOS) Google Group, associated with Steve Freeman and Nat Pryce’s terrific book of the same name. Someone had dropped a note pointing to Brain Swan’s provocatively titled presentation “Mocks Suck.” A fascinating dialogue ensued, led by Steve, Nat, Brian, Joe Rainsberger and others.

As I watched that conversation, two things stood out for me. First was that the “tell, don’t ask” principle (aka The Law of Demeter) kept coming up. Second was the repeated assertion that JMock’s strictness (its rejection by default of any method call you didn’t tell it to expect) was not a damned nuisance at all, but actually a good thing, because it points to problems in the code.

Though I’d heard both of these ideas before (I first read about the Law of Demeter in 1990 when I was writing C++ code), and applied them half-heartedly, I’d never given them my full attention. But Steve, Nat, and Joe are all really smart, and I’d learned much from them in the past. So when they all repeated these ideas within a few hours of each other, I sat up and took notice. As they explained their approach to mocking, I began to see that strict mocking and “tell, don’t ask” were at least more nuanced than I’d thought, if not more powerful.

The Itch.I got the itch to apply these two “new” ideas mindfully. And I added a third idea that I had been practicing for a while, but which suddenly made more sense in light of the GOOS conversation: Develop applications from the outside in.

Suddenly I had a new intention for Towers. In addition to writing a sample application in my workshop, I could also create a workshop for myself, an opportunity to apply these three ideas and see what I could learn.

So I began applying “tell, don’t ask” to my existing Towers code. After a few days of that I began to feel lost and backed off. (You may follow that trail from the clearly marked commit on Jan 12 if you wish. I haven’t the heart.) I spent a day away from the code, then decided to start the whole app over in a fresh repo.

A Blunt Instrument. Several coding-hours into my third take, I found myself struggling to configure three different mocks for one class I was testing. After I’d thrashed a bit, something hit me like a can of Spam to the forehead: This was one of those situations Steve, Nat, and Joe had talked about. The problem was not that the mocks were difficult to set up. The problem was that my simple class required three collaborators.

A Blunter Blunt Instrument. A few commits later I’d fixed the problem, and was excited by what I’d learned. I tweeted (in a way that was perhaps easy to misinterpret as criticism of JMock): “Using JMock for the first time. Noticed 3 mocks in one test. Ugh. Started refactoring. Ended up with one dependency, no mocks.”

Within minutes, Steve replied “Post example code please?” Seconds later, Nat added, “Are you going to write up your experience?”

I promised to post some code, but hesitated about writing up my experience. “I don’t know yet,” I said. “I’m too new with ‘tell, don’t ask’ to have a feel for what I’m doing.”

Then Yves Hanoulle hit me with this blunt instrument: “Why is being new an excuse for not writing down?”

Dammit, he’s right. Double dammit.

So I started writing a short blog post about what had happened in the “three mocks” incident. As I scoured my (frequent) git commits to find reference points for my blog post, I found myself studying my process. What had I done? What had my reasoning? What had the results been? Then I discovered that there were things to learn from even earlier in this hours-old project, starting with my very first decision, my choice of “walking skeleton.” And suddenly I was learning from the process of writing.

The Thing. And that post turned into two. And then I thought I could make it a series (just in case I learn anything else, and just in case that’s interesting to anyone). And then I needed to write this introduction. And now it’s becoming a thing. (Dammit, Yves!)

So this post is my introduction to the thing. Two more posts are in the works, each nearly complete. One describes the “three mocks” problem. The other describes the earlier code and the “walking skeleton” problem. Beyond that, who knows?

Before JUnit runs a test, it knows something about the test. When the test ends, JUnit knows something about the results. Sometimes we want test code to have access to that knowledge, or even to alter details about a test, the results, or the context in which the test runs.

Older versions of JUnit offered no easy way for test code to do those things. Neither test class constructors nor test methods were allowed to take parameters. Each test ran in a hermetically sealed capsule. There was no simple API to access or modify JUnit’s internal knowledge about a test.

That’s what rules are for. JUnit rules allow us to:

• Add information to test results.
• Access information about a test before it is run.
• Modify a test before running it.
• Modify test results.

Adding Information to Test Results

A few months ago I was working with testers at a client, automating web application tests using Selenium RC. The tests ran under Hudson on our continuous integration servers. The Selenium server ran in the cloud using Sauce Labs’ Sauce On Demand service.

Information about each test run was available in two places. First, Hudson creates a web page for each test run, including a printout of any exception raised by the test. Second, Sauce On Demand creates a job for each test run, and a web page for each job, which displays a log of every Selenium command and its result, links to screenshots taken just before each Selenium command that would change the state of the browser, and a video of the entire session.

To make it easier to find information about test failures, we wanted a way to link from the Hudson test report to the Sauce Labs job report. Determining the URL to the Sauce Labs job report was easy; our test framework knew how to do that. But we didn’t know how to insert the URL into the Hudson test report. Given that we needed to display the URL only when a test failed, we decided that the easiest solution was to somehow catch every exception, and wrap it in a new exception whose message included the URL. When Hudson printed the exception, the printout would display the URL.

The challenge was: How to catch every exception? For the exceptions thrown directly by our own test code, wrapping them was easy. But what to do about exceptions thrown elsewhere, such as by Selenium? Sure, we could wrap every Selenium call in a try/catch block, but that seemed troublesome.

One possibility seemed promising: Given that every exception eventually passed through JUnit, perhaps we could somehow hook into JUnit, and wrap the exception there. But how to hook into JUnit?

I tweeted about the problem. Kent Beck replied, telling me that my problem was just the thing Rules were designed to help with. He also sent me some nice examples of how write a rule and (of course) how to test it.

With Kent’s helpful advice and examples in hand, I was able to quickly write a rule that did exactly what my client and I needed:

public class ExceptionWrapperRule implements MethodRule {
    public Statement apply(final Statement base, FrameworkMethod method, Object target) {
        return new Statement() {
            public void evaluate() throws Throwable {
                try {
                    base.evaluate();
                } catch (Throwable cause) {
                    throw new SessionLinkReporter(cause);
                }
            }
        };
    }
}

In our test code, at the point where we establish the Selenium session, we obtain the session ID from Selenium and stash it. If the test fails, the ExceptionWrapperRule’s statement catches it and wraps it in a SeleniumLinkReporter (an Exception subclass we defined). The SeleniumLinkReporter constructor retrieves the stashed session ID, builds the Sauce On Demand job report link, and stuffs it into its exception message.

So this is an example of the first major use of rules: To modify test results by adding information obtained during the test.

Accessing Information About a Test Before It Is Run

At that same client, we learned of a new Sauce On Demand feature that we wanted to use: SauceTV. SauceTV displays a video of the browser while your test is running. As we wrote new tests, changed the features of the web application, and accessed new features of Sauce On Demand, we found ourselves often wanting to watch tests as the executed.

Sauce Labs provides a web page that displays two lists of open jobs for your account: Your jobs that are currently running, and your jobs that are queued to run. To access the video for a test in progress, you click the name of the appropriate job.

By default, each job’s name is its Selenium session ID, a long string of hexadecimal digits. Even if you know the session ID, it is difficult to quickly distinguish one long hexadecimal string from another. To help with this, Sauce Labs allows you to assign each job a descriptive name to display in the job lists. You do this by sending a particular command to its Selenium server.

Given that we were running one test per job, the obvious choice for the job name is the name of the test. But how to access the name of the test? Certainly we could add a line like this to each test:

@Test public void myTest() {
    sendSauceJobName("myTest");
}

But that’s crazy talk. Much better would be a way to detect the test name at runtime, in a single place in the code. How to detect the test name? Rules to the rescue. We wrote this rule:

public class TestNameSniffer implements MethodRule {
    private String testName;

    public Statement apply(Statement statement, FrameworkMethod method, Object target) {
        String className = method.getMethod().getDeclaringClass().getSimpleName();
        String methodName = method.getName();
        testName = String.format("%s.%s()", className, methodName);
        return statement;
    }
    
    public String testName() {
        return testName;
    }
}

The rule stashes the test name, and other code later sends the name to Selenium RC. Now Sauce Labs labels each job with the name of the test, which is much easier to recognize than hexadecimal strings.

Modifying a Test Before Running It

In a Twitter conversation about what rules are good for, Nat Price said, “JMock uses a rule to perform the verify step after the test but before tear-down.” JMock is a framework that makes it easy to create controllable collaborators for the code you’re testing, and to observe whether your code interacts with them in the ways you intend.

To use JMock in your test code, you declare a field that is an instance of the JUnitRuleMockery class:

public class MyTestClass {
    @Rule
    public JUnitRuleMockery context = new JUnitRuleMockery();
    
    @Mock
    public ACollaboratorClass aCollaborator;
    
    @Test
    public void myTest() {
        ... // Declare expectations for aCollaborator.
        ... // Invoke the method being tested.
    }
}

JUnitRuleMockery is a rule whose apply() looks like this:

@Override
public Statement apply(final Statement base, FrameworkMethod method, final Object target) {
    return new Statement() {
        @Override
        public void evaluate() throws Throwable {
            prepare(target);
            base.evaluate();
            assertIsSatisfied();
        }
        
        ... // Declarations of prepare() and assertIsSatisfied()
    }
}

Before the statement executes the test, it first calls prepare(), which initializes each mock collaborator field declared by the test class. For the example test class, prepare() initializes aCollaborator with a mock instance of ACollaboratorClass.

Initializing fields in the target is an example of a second use for rules: Modifying a test before running it.

Modifying Test Results

The JMock code also demonstrates another use for JUnit rules: Modifying test results. After the test method runs, the assertIsSatisfied() method evaluates whether the expectations expressed by the test method are satisfied and throws an exception if they are not. Even if no exception was thrown during the test method itself, the rule might throw an exception, thereby changing a test from passed to failed.

• Before running a test, send the name of the test to Sauce Labs to create captions for SauceTV.
• Instruct Swing to run a test headless.
• Insert the Selenium session ID into the exception message of a failed test.

Overview of Rules

Parts. The JUnit rule mechanism includes three main parts:

• Statements, which run tests.
• Rules, which choose which statements to use to run tests.
• @Rule annotations, which tell JUnit which rules to apply to your test class.

Flow. To execute each test method, JUnit conceptually follows this flow:

1. Create a default statement to run the test.
2. Find all of test class’s rules by looking for public member fields annotated with @Rule.
3. Call each rule’s apply() method, telling it which test class and method are to be run, and what statement JUnit has gathered so far. apply() decides how to run the test, selects or creates the appropriate statement to run the test, and returns that statement to JUnit. JUNit then passes this statement to the next rule’s apply() method, and so on.
4. Run the test by calling the evaluate() method of the statement returned by the last rule.

I’ll describe the flow in more detail in the final section, below. Now let’s take a closer look at the parts, with an example. (The code snippets are available as a gist on GitHub.)

Writing Statements

A statement executes a test, and optionally does other work before and after executing the test. You write a new statement by extending the abstract Statement class, which declares a single method:

public abstract void evaluate() throws Throwable;

A typical evaluate() method acts as a wrapper around another statement. That is, it does something before the test, calls another statement’s evaluate() method to execute the test, then does something after the test.

Here is an example of a statement that invokes the base statement to run the test, then takes a screenshot if the test fails:

public class MyTest {
    @Rule
    public MethodRule screenshot = new ScreenshotOnFailureRule();

    @Test
    public void myTest() { ... }

    ...
}

Writing Rules

A rule chooses which statement JUnit will use to run a test. You write a new rule by implementing the MethodRule interface, which declares a single method:

Statement apply(Statement base, FrameworkMethod method, Object target);

The parameters are:

• method: A description of the test method to be invoked.
• target: The test class instance on which the method will be invoked.
• base: The statement that JUnit has gathered so far as it applies rules. This may be default statement that JUnit created, or a statement created by another rule.

The purpose of apply() is to produce a statement that JUnit will later execute to run the test. A typical apply() method has two steps:

1. Create a statement instance.
2. Return the newly created statement to JUnit.

Note that when JUnit later calls the statement’s evaluate() method, it does not pass any information. If the statement needs information about the test method, the test class, how to invoke the test, or anything else, you will need to supply that information to the statement yourself (e.g. via the constructor) before returning from apply().

Almost always you will pass base to the new statement’s constructor, so that the statement can call base’s evaluate() method at the appropriate time. Some statements need information extracted from method, such as the method name or the name of the class on which the method was declared. Others do not need information about the method. It’s rare that a statement will need information about target. (The only one I’ve seen is the default one that JUnit creates to invoke the test method directly.)

Often, there is no decision to make. Simply create the statement and return it, as in this example:

public class ScreenshotOnFailureRule implements MethodRule {
    @Override
    public Statement apply(Statement base, FrameworkMethod method, Object target) {
        String className = method.getMethod().getDeclaringClass().getSimpleName();
        String methodName = method.getName();
        return new ScreenshotOnFailureStatement(base, className, methodName);
    }
}

In situations that are not so simple, you can compute the appropriate statement depending on information about the test method. For example, you may wish to suppress screenshots for certain tests, which you indicate the @NoScreenshot annotation. Your screenshot rule can choose the appropriate statement depending on whether the annotation is present on the method:

public class ScreenshotOnFailureRule implements MethodRule {
    @Override
    public Statement apply(Statement base, FrameworkMethod method, Object target) {
        if(allowsScreenshot(method)) {
            String className = method.getMethod().getDeclaringClass().getSimpleName();
            String methodName = method.getName();
            return new ScreenshotOnFailureStatement(base, className, methodName);
        }
        else {
            return base;
        }
    }

    private boolean allowsScreenshot(FrameworkMethod method) {
        return method.getAnnotation(NoScreenshot.class) == null;
    }
}

A note about upcoming changes in the rule API

In JUnit 4.9—the next release of JUnit—the way you declare rules will change slightly. The MethodRule interface will be deprecated, and the TestRule interface added in its place. The signature of the apply() method differs slightly between the two interfaces. As noted above, the signature in the deprecated MethodRule interface was:

Statement apply(Statement base, FrameworkMethod method, Object target);

The signature in the new TestRule interface is:

Statement apply(Statement base, Description description);

Instead of using a FramewordMethod object to describe the test method, the new interface uses a Description object, which gives access to essentially the same information. The target object (the instance of the test class) is no longer provided.

Applying Rules

To use a rule in your test class, you declare a public member field, initialize the field with an instance of your rule class, and annotate the field with @Rule:

public class MyTest {
    @Rule
    public MethodRule screenshot = new ScreenshotOnFailureRule();

    @Test
    public void myTest() { ... }

    ...
}

The Sequence of Events In Detail

JUnit now applies the rule to every test method in your test class. Here is the sequence of events that occurs for each test (omitting details that aren’t related to rules):

1. JUnit creates an instance of your test class.
2. JUnit creates a default statement whose evaluate() method knows how to call your test method directly.
3. JUnit inspects the test class to find fields annotated with @Rule, and finds the screenshot field.
4. JUnit calls screenshot.apply(), passing it the default statement, the instance of the test class, and information about the test method.
5. The apply() method creates a new ScreenshotOnFailureStatement, passing it the default statement and the names of the test class and test method.
6. The ScreenshotOnFailure() constructor stashes the default statement, the test class name, and the test method name for use later.
7. The apply() method returns the newly constructed screenshot statement to JUnit.
8. (If there were other rules on your test class, JUnit would call the next one, passing it the statement created by your screenshot rule. But in this case, JUnit finds no further rules to apply.)
9. JUnit calls the screenshot statement’s evaluate() method.
10. The screenshot statement’s evaluate() method calls the default statement’s evaluate() method.
11. The default statement’s evaluate() method invokes the test method on the test class instance.
12. (Let’s suppose that the test method throws an exception.)
13. Your screenshot statement’s evaluate() method catches the exception, calls the MyScreenshooter class to take the screenshot, and rethrows the caught exception.
14. JUnit catches the exception and does whatever arcane things it does when tests fail.

In the spur of the moment, I invented an elaboration: “What one small thing will you commit to doing? What’s the smallest thing you can commit to?”

One man asked, “How small?” I said, “Smaller than that.” He laughed, because my kinda non-answer answer seemed funny. Then he immediately thought of something. “Aha!” he said, and started to write. Another man still didn’t understand, so I offered a bound: “Something you could do all on your own before noon on Monday.” That made sense to him, and he began to write. And everybody else wrote. The two people who had started to gather their belongings sat down and wrote.

That spontaneous refinement worked so well that I now often end workshops with the One Small Thing activity: What one small thing will you commit to doing? Something you could do all on your own before noon? Write it down.

Over the years I’ve learned what makes this simple activity so powerful. First, people can almost always find something to commit to. If they are reluctant to commit to a given action, there’s almost always a smaller action that they will commit to fully, with enthusiasm. One small thing. How small? Smaller than that. What kind of thing? Anything that you will commit to.

Second, when invited to commit to one small thing, people always find something that matters to them. So small doesn’t mean unimportant.

Third, people are good at keeping small commitments. Keeping one small commitment starts a ball rolling—or continues one, for people who already make and keep personal commitments.

Fourth, once people see that keeping even a small commitment has good effects, and feels good in and of itself, they realize that they can make their lives better even in small steps.

When people finish writing, I invite them to share their commitments if they wish. Almost always there’s a pause. Then someone shares. Then someone else. After the first few, other people begin to feel safer. Usually about a third of the people in the room will share their commitments, and then we’re done.

As I invite people to share, I make it clear that sharing is entirely voluntary, and that it’s okay to keep these commitments private and personal. At a recent workshop, one woman approached me after the activity and said, “Originally I wrote down something I didn’t really care about. When I saw that you really weren’t going to make us say our commitments out loud, I realized that this wasn’t for you, it was for me. So I changed my commitment to something that matters to me. It matters a lot.”

Imagine a certification that no hirer cared about, that no hirer ever used as a factor when determining whether to hire someone, or how much to pay them. Would such a certification thrive as a certification? Would it survive? If the certification offered sufficient prestige, some practitioners may seek it as a badge of honor, a point of pride. But as a certification per se?

Hirers who can accept moderate or low skill don’t need certifications. Hirers who can assess skills themselves don’t need certifications. Certifications matter because hirers need help assessing skills that matter.

I offer this test of the value and legitimacy of a certification program: To what extent does it help hirers make high quality hiring decisions?

Whatever benefits of a certification program may provide for others, they are secondary. Any certification program that serves other needs for other people, but does not help hirers make high quality hiring decisions, is a swindle. Any certification program that serves other people’s needs at the expense of those hirers’ needs is a fraud.

I propose The Certification Prime Directive: Above all else, help hirers make high quality hiring decisions.

• The problem in general.
• The desired state, the perceived state, and the difference between the two.
• The way the problem is stated.
• The problem’s past, present, and future.
• The way the problem is being solved.
• The way you are exploring the problem.

Early in the video, Santos asked a question that caught my attention: “How is a species that’s as smart as we are capable of such bad and consistent errors?”

What I find most interesting about Santos’s question is a presupposition: The question tacitly posits “as smart as we are” as the standard of judgment. Why do I say “tacitly,” when she clearly states the standard in her question? Though the standard is explicit, what’s tacit is taking that standard as a given.

To demonstrate, I’ll ask a different question: “For a species that consistently makes such bad errors, how is it that we are as smart as we are?” My question posits a different baseline for evaluating our behavior: Our consistent errors.

In my tweets on this subject, I called Santos’s question a “foreground/background error.” That was a mistake. Rather, Santos makes a foreground/background choice. Her question and mine differ in the choice of background and foreground. Her question places human smartness in the background and consistent errors in the foreground. My question reverses the foreground and background.

We humans often ask such questions, which make an implicit choice of what to place in the foreground and what in the background.

For example, people ask, “Why do we sleep?” The question (tacitly) takes awakeness as background. I think it’s probably more reasonable and fruitful to ask, “Why are we ever wake?” The vast majority of living things are never awake. We and other animals do sometimes wake. How does that happen? I think it’s miraculous.

Another example, which I hear a lot: “Why do we miscommunicate so much?” Flip the foreground and background: “How is it that we are ever able to communicate at all?” Communication is a freaking miracle, and our oft-uttered question takes it for granted.

Matt Heusser tweeted another example from a forum on communication between managers and doers: “Why is there so much friction between managers and doers?” Matt flipped the question: “With so much conflict inherent in our systems, isn’t it a miracle that we ever get anything done?”

We could state our observations relatively neutrally, with equal emphasis: We’re as smart as we are; we consistently make bad errors. But typically we don’t do that. We place one observation in the background, and apply it as a standard against which to judge the other observation.

What fascinates me is that our questions typically place the more “perfect” standard in the background, even though the evidence suggests that humans don’t live up to the standard. What’s more, we typically ask such questions directly in response to noticing that we don’t live up to the standard. We take as given a standard that we know we don’t meet. We humans seem to have a bias toward judging ourselves against standards of perfection.

This is not an idle topic for me. It’s at the heart of my coaching. My clients often lament that they fall short of some standard they have set for themselves. As we explore the standard, we often find that the standard is very difficult to meet, and sometimes beyond human capability. And yet clients make great effort to continue to hold onto their standards, even after agreeing that the standards are unreasonable.

How come we so often choose as background a standard that we clearly do not meet? What would happen if we more often made a different choice, to take our typical experience as the standard, and ask how we are sometimes able to be better than that?

What if how actually we observe ourselves to be were okay, even as we yearn to be “better”?

Of course, my entire post implicitly posits its own standard of perfection: A standard of not judging ourselves against standards that we demonstrably fail to live up to.

Maybe I can soften my own error this way: When we notice that we are holding ourselves and each other to some standard of perfection, we have an opportunity to make the standard explicit, ask whether and how it serves us, and explore other standards that may serve us better.

Bob’s podcasts are always conversational—the conversation wanders where it will, but seldom strays far from the topic du jour. Our wanderings touched on:

• Resistance is mutual
• Bridging the gap between hamsters and wolverines
• Solving the deeper problem is sometimes easier than solving the surface problem
• Ineffective patterns of coping with stress (blaming, placating, distracting)
• Joe diffuses the boss’s boss’s boss’s boss’s boss’s blaming
• The power of aggregation
• The power of giving yourself choices
• Payson Hall’s terrific keynote about the dilemmas of risk management
• Dale fails to grok space and time
• Three definitions of resistance
• Overcoming resistance (boo!) versus resolving resistance (yay!)
• Resistance is feedback
• To encourage change, start by meeting people where they are
• Two styles of Agile adoption: “By the book” and evolutionary
• From balance to differentiation—from “how much” to “which”
• My upcoming Resistance as a Resource workshop at Agilistry Studio, July 14–15

Only in retrospect could I name the central topic of our chat: social challenges at work. In further retrospect, that central topic is nearly inevitable, given my interests.

Problems and Problem Statements

In Are Your Lights On?, Don Gause and Jerry Weinberg offer this useful definition of problem:

A problem is a difference between things as perceived and things as desired.

I like this definition because it highlights three important elements of any problem: things as perceived, things as desired, and a difference between the two.

There’s another important element of any problem: The person who is perceiving and desiring things. In order for the difference between things as perceived and things as desired to be a problem, the perceiver and the desirer must be the same person.

A problem statement is a model of the problem, a simplification designed to aid in solving the problem. Like any model, a problem statement differs from the thing being modeled. A good model highlights features that are most relevant to the modeler’s purpose and hides details that are less relevant. A good problem statement highlights problem elements that help solve the problem, and hides details that distract.

Problem Statement Smells

A problem statement smell is any element of a problem statement that makes the problem harder to solve. Some smells attract your attention toward conditions that are inessential to the problem, or that are beyond your influence. Some smells divert your attention away from an essential element of the problem.

Problem statement smells commonly take three forms: additions, deletions, and distortions. Some problem statements combine several smells.

Additions

Some problem statements introduce claims and ideas that are not present in the problem itself. These additions can confuse problem solvers, lead to wild goose chases, or otherwise distract from the problem.

Conclusions expressed as facts. I need to give my boss the test results for third-party authorization, but Jeff isn’t done testing it yet. How do you know Jeff isn’t done? What did you see or hear that led to that conclusion? Perhaps Jeff is already done, and is writing up his report right now.

Mindreading. Jeff is just trying to protect his own turf. You have no direct access to Jeff’s thoughts and intentions. What did you see or hear that led to that conclusion? What are two other possible meanings of what you saw and heard?

Solution probleming. The problem is that we don’t have a Wiki for test status. This is a solution in search of a problem. What’s the problem? If you had a Wiki, what would that do for you? Often, the “problem behind the problem” is easier to solve.

Missing standard. Jeff tests too slowly. Too slowly for what? What would be fast enough? How do you assess how fast he tests?

Deletions

Many problem statements omit important elements of the problem. These omissions can make it harder to envision what a solution would look like.

Missing desire. The problem is that Jeff is only halfway finished testing third-party authorization. That’s the perceived state. What’s the desired state?

Missing perception. The problem is that I need Jeff to finish testing third-party authorization by Monday. That’s the desired state. What’s the perceived state?

Missing problem stater. The problem is that Jeff is supposed to be done testing third-party authorization, and he isn’t done yet. The person who stated the problem is mentioned nowhere in the problem statement. Who is doing the supposing? Whose problem is this?

Missing actor. Some of the items on the backlog seem to have no owner. Rephrase to add an actor: I cannot identify the owner for some of the backlog items.

Distortions

Many problem statements amplify problem elements, or dampen them, or interpret them in distorted ways. Such distortions, if we take them as truths, limit the kinds of solutions we will consider.

“Can’t.” I can’t ask for a bigger budget. Try: “I choose not to ask for a bigger budget because I want _____.” (Fill in the blank.) What stops you from asking for a bigger budget? What would happen if you asked for a bigger budget?

“Have to.” I have to work this weekend. Try: “I choose to work this weekend because I want _____.” (Fill in the blank.) What would happen if you didn’t work this weekend?

Inanimate agent. The problem is that our backlog just keeps growing. Backlogs can’t just grow of their own accord. Somebody is growing it. Who? How?

Lullaby language. No problem. We should just work weekends until we ship. Words and phrases such as should, no problem, and just tend to minimize the complexity of the problem, directing attention away from important details. Question each use of these “lullaby words” to surface the hidden assumptions. See Jerry Weinberg’s More Secrets of Consulting for further examples of lullaby language.

Combinations

Sometimes a single problem statement will include a combination of additions, deletions, and distortions.

Judgment. The problem is that Jeff has no initiative. One smell: mindreading. What do you see and hear that leads you to this conclusion? Another smell: missing desire. What do you want from Jeff? A third smell: tacit causation. Even if Jeff had tons of initiative, he might apply it elsewhere, and still not do what you need.

Tacit causation. Customers expect me to remember all of their requests, so I add them to the backlog, and the backlog just keeps getting bigger. The little word “so” suggests causation, but the link between cause and effect is neither obvious nor stated. But there is no law of the universe that says “if customers expect you to remember their requests, you must add them to the backlog.” That’s one way to respond to the expectation. What are some other ways?

Other time or place. Jeff didn’t finish testing third-party authorization. That’s in the past, and you can’t alter that. What problem are you experiencing right now? What need is currently unfulfilled?

Your Turn

Experiment: What other problem statement smells can you identify? How might you remedy each?

Experiment: In my description of each problem statement smell, I describe or hint at some of the problems caused by the smell. My problem statements have smells. What smells can you identify?

The layering per se wasn’t a surprise, because automated tests are software, and software tends to organize into layers. But lately I’ve noticed a pattern. The layers in my automated tests center around four themes:

• Test intentions
• System responsibilities
• Essential system interface
• System implementation interface

Test intentions. Test names and suite names are the top layer in my automation. If I’ve named each test and suite well, the names express my test intentions. Reading through the test names, and seeing how they’re organized into suites, will give useful information about what I tested and why.

For example, in my article on “Writing Maintainable Automated Acceptance Tests” (PDF), I was writing tests for a system’s account creation feature, and specifically for the account creation’s responsibility to validate passwords. I ended up with these test names (see Listing 7):

• Rejects passwords that omit required character types
• Rejects passwords with bad lengths
• Accepts minimum and maximum length passwords

In an excellent video followup to my article, Bob Martin organized his tests differently, using FitNesse. He grouped tests into two well-named suites, “Valid passwords” and “Invalid passwords.” Each suite includes a number of relevant example passwords, each described with a comment that expresses what makes the example interesting.

Every test tool that I’ve used offers at least one excellent way to express the intentions of each test. However expressed, those intentions become the top layer of my automated tests.

System responsibilities. A core reason for testing is to learn whether the system meets its responsibilities. As I refine my automation, refactoring it to express my intentions with precision, I end up naming specific system responsibilities directly.

In my article, I’m testing a specific pair of responsibilities: The account creation command must accept valid passwords and reject invalid ones. As I refactored the duplication out of my initial awkward tests, these responsibilities emerged clearly, expressed in the names of two new keywords: Accepts Password and Rejects Password. Listing 7 shows how my top-level tests build on these two keywords.

Essential system interface. By system interface, I mean the set of messages that the system sends and receives, whether initiated by users (e.g. commands sent to the system) or by the system (e.g. notifications sent to users).

By essential I mean independent of the technology used to implement the system. For example, the account creation feature must offer some way for a user to command the system to create an account, and it must include some way for the system to notify the user of the result of the command. This is true regardless of whether the system is implemented as a command line app, a web app, or a GUI app.

As I write and refine automated tests, I end up naming each of these essential messages somewhere in my code. In my article, Listing 2 defines two keywords. “Create Account” clearly identifies one message in the essential system interface. Though the other keyword, “Status Should Be,” is slightly less clear, it still suggests that the system emits a status in response to a command to create an account. (Perhaps there’s a better name that I haven’t thought of yet.) Listing 4 shows how the higher-level system responsibility keywords build upon these essential system interface keywords.

System implementation interface. The bottom layer (from the point of view of automating tests) is the system implementation interface. This is the interface through which our tests interact most directly with the system. Sometimes this interaction is direct, e.g. when Java code in our low-level test fixtures invoke Java methods in the system under test. Other times the interaction is indirect, through an intermediary tool, e.g. when we use Selenium to interact with a web app or FEST-Swing to interact with a Java Swing app.

In my article, I tested two different implementations of the account creation feature. The first was a command line application, which the tests invoked through the “Run” keyword, an intermediary built into Robot Framework. Listing 2 shows how the Create Account keyword builds on top of the Run keyword (though you’ll have to parse through the syntax junk to find it).

The second implementation was a web app, which the tests invoked through Robot Framework’s Selenium Library, an intermediary which itself interacts through Selenium, yet another intermediary. Listing 8 shows how the revised Create Account keyword builds on various keywords in the Selenium Library.

Translating Between Layers

Each chunk of test automation code translates an idea from one layer to the next lower layer. Listing 7 shows test ideas invoking system responsibilities. Listing 4 shows responsibilities invoking messages in the essential system interface. Listings 2 and 8 show how the essential system interface invokes two different system implementation interfaces.

Each of the acceptance test tools I use allows you to build layers like this. In FitNesse, top-level tests expressed in test tables may invoke “scenarios,” which are themselves written in FitNesse tables. And scenarios may invoke lower-level scenarios. In Cucumber, top-level “scenarios” invoke “test steps,” which may themselves invoke lower-level test steps. In Twist, “test scenarios” invoke lower-level “concepts” and “contexts.” Each tool offers ways to build higher layers on top of lower layers, which build upon yet lower layers, until we reach the layer that interacts directly with the system we’re testing.

In the examples in my article, I chose to write all of my code in Robot Framework’s keyword-based test language. I defined each keyword entirely in terms of lower-level keywords. I could have chosen otherwise. At any layer, I could have translated from the keyword-based language to a more general purpose programming language such as Java, Ruby, or Python. The other tools I use offer a similar choice.

But I, like many users, find these tools’ test languages easier for non-technical people to understand, and sufficiently flexible to allow users to write tests in a variety of ways. In general, I want as many of these layers as possible to be meaningful not just to technical people, but to anyone who has knowledge of the application domain. So I like to stay with the tool’s test language for all of these layers, switching to a general purpose programming language only at the lowest layer, and then only when the system’s implementation interface forces me to.

A Lens, Not a Straightjacket

When I write automated tests for more complex applications, there are often more layers than these. Yet these four jump out at me, perhaps because each represents a layer of meaning that I always care about. Every automated test suite involves test ideas, system responsibilities, the essential system interface, and the system’s implementation interface. Though other layers arise, I haven’t yet identified additional layers that are so universally meaningful to me.

These layers were a discovery for me. They offer an interesting way to look at my test code to see whether I’ve expressed important ideas directly and clearly. I don’t see them as a standard to apply, or a procrustean template to wedge my tests into. They are a useful lens.

I’m fascinated by tradeoffs, and I often drive myself nuts making them – I go back and forth and back and forth and… And at some point, I’ll identify the qualities that I’m trying to trade off (expressiveness, test speed, number of places I’d have to change if the code or the requirements change) and move on. Until the next time I visit that file. Then I’ll go back and forth and back and forth… I am very good at revisiting decisions, and not so good at sticking with a decision I made in the past – even minutes in the past.

Chris’s suggestion points out that there are two pieces of information we’re trying to encode into the name: The idea that passwords have a minimum and maximum valid length, and the specific minimum and maximum (6 and 16 characters). I went with one of those pieces of information, Chris went with the other.

As Chris points out, each style leaves readers to infer something important. With Chris’s style, readers must infer what’s special about any given length. With my style, readers must infer what specific lengths form the boundaries. Neither style expresses both pieces of information explicitly – e.g. that the maximum legal length is 16 characters. There’s a tradeoff here: Which piece of information to express? And by making that tradeoff differently, each style not only expresses one piece of information, but also emphasizes it. My style emphasizes the idea of minimum and maximum lengths; Chris’s style emphasizes the specific lengths themselves.

Also, Chris points out (and I agree) that my style requires readers to count string lengths, a tedious, error-prone chore.

Given all of that: Which style do you prefer? More importantly: What do you prefer about it?

Sometimes I can easily see how to trade off possibilities. Other times I can’t see a clear winner. For those times, I recommend experimenting. Try each possibility. Then pay attention to what happens.

In this case, there’s another criterion I can apply: With Chris’s tests, the length of each password appears three times: Once implicitly in the password itself, once in the declaration of the variable, and once in the test that references each variable. Expressing that specific datum three times is potentially troublesome: If we increase the maximum length of a password to 20, we’d have to change six places (three places for a max length password, three places for a password that’s too long). With my style, we’d have to change only two places: the passwords themselves. The variable names would remain the same.

Though I’m not entirely sure which style emphasizes the more important bit of information, the criterion of “how many places I’d have to change” leaves me preferring the style I used in the article. Chris might still reasonably prefer his style, if the extra expressiveness he perceives is valuable enough to outweigh the extra cost of change.

So far, I still prefer my original variable names to Chris’s. And yet his suggestion, his thoughtful explanation of why he prefers it, and especially the contrast it provides with my original tests, make me wonder: Now that we know what we’re trading off, can we find a way to eliminate the tradeoff altogether? Is there another style that allows us to express all of the information we want to express, and without increasing the cost of change?

Uncle Bob, in his video, offers a third style: Instead of conveying information through variable names, express it through comments. His comments express something similar to my variable names: maximumness and minimumness. It would be easy enough to add the information that Chris’s variable names express and that mine lack: “16 characters is just short enough” and “6 characters is just long enough”. I’ve unfortunately trained myself to feel queasy whenever I start to type a comment into code. I’m going to have to get over that. Writing a comment is not necessarily evil; it’s just a tradeoff.

Contrasting my tests to Uncle Bob’s, I notice yet another tradeoff: How to organize tests into suites? I organized my tests around specific validity criteria: One set of tests for character content requirements, another for length requirements. Uncle Bob organized the same tests differently: One set of tests for valid passwords, another for invalid passwords. And each way of organizing requires us to name our groupings, which offers an opportunity to subtly highlight one piece of information or the other. My organization emphasizes that are two classes of validity criteria, content and length. Uncle Bob’s emphasizes that passwords may be valid or invalid.

Which emphasis do you prefer? More importantly: What do you prefer about it?

A few final points about tradeoffs. If you want to get better at making tradeoffs such as these, step one is to notice what tradeoffs you’re making. And a great way to do that is to pair with someone. I wrote the tests on my own, and in the article I mentioned the tradeoffs I was aware of making. But I made other tradeoffs implicitly, without noticing I was making them. It was only when Chris and Bob offered alternatives that I noticed I was making those tradeoff at all.

Thanks Chris and Bob for inviting me to explore the tradeoffs I make, and how I make them!

The article demonstrates how to make automated acceptance tests more maintainable by:

• Hiding incidental details
• Eliminating duplication
• Naming essential ideas

Though the examples in the article use a very nice testing framework called Robot Framework, the ideas work just as well with other other popular open-source testing frameworks, such as FitNesse and Cucumber.

You will be able to follow the article even if you don’t know Robot Framework. But don’t be surprised if it inspires you to give Robot Framework a try.

Here’s how to tell whether you’re asking too much: How do you feel when you don’t get it?

I suppose some managers see people as resources, replaceable, fungible, interchangeable cogs in the corporate machine. My sense is that few managers who use the term “human resources” use it in that way. And still the term rankles.

I don’t often use the term myself. And when I hear it, I interpret it to mean resources that originate in people, in much the same way that natural resources refers not to nature per se as a resource, but to resources that originate in nature. The human resource is not the person, but something that the person offers to the organization.

Several years ago, Jerry Weinberg offered a nice idea for what that resource is. I don’t remember Jerry’s exact words, so I’ll paraphrase from my perhaps faulty memory: The resource is the person’s agreement with the organization. The resource is the person’s agreement to contribute to organizational ends.

I liked that idea, and I’ve kept it in mind ever since, whenever the “human resource” complaints crop up.

Today I found another idea. On Twitter, Brian Marick quoted a New York Times article by Jon Mooallem: “[Sandpoint, Idaho council member John] Reuter seemed to argue that enthusiasm is an actual asset, a resource our society is already suffering a scarcity of.”

And my synapses made a connection: Enthusiasm is the human resource. Especially in knowledge work, the primary human resource is people’s enthusiasm for the the organization’s purposes and for the work that serves those purposes.

What I like about this notion is that it is more dynamic than “human resource” or even “the person’s agreement.” A person’s enthusiasm can wax and wane. We can nurture it, squander it, squash it. We as leaders have a great deal of influence over how much enthusiasm exists in our organizations, and how much is available for the organization. And it’s not only renewable, but potentially non-diminishable: We can use people’s enthusiasm in ways that leave them even more enthusiastic than they were before. And enthusiasm is catching.

By the way, though I’m convinced that distinguishing between management and leadership is an utter waste of time, I’m gonna do it anyway: A manager deploys people’s enthusiasm toward organizational purposes. A leader (in an organization) nurtures, cultivates, grows, invites, coaxes, inspires people’s enthusiasm for organizational purposes.

(Yes, I know that enthusiasm is only one thing people offer their organizations, so the human resource doesn’t tell the whole story. Of course skills and knowledge matter, too, and a host of other things. But today I’m enthusiastic about enthusiasm, so I’m taking a little blogistic license.)

A system responsibility includes three parts:

• A stimulus that triggers the system to respond to an event.
• A context in which the system is required to respond to the stimulus.
• A set of results that the system is obligated to realize in response to that stimulus in that context.

Stimulus. A stimulus is a message, sent by someone or something outside the boundary of the system, that informs the system of an event to which it is obligated to respond. The stimulus has a name, which may identify either the event that it represents or the planned response that the system must carry out. The stimulus may include additional information about the event.

Stimuli are delivered to a system through its interfaces. An interface defines a set of messages to which a system responds, and the mechanisms by which those messages are delivered. For GUI systems, the interface includes a suite of windows, forms, buttons, text fields, and other mechanisms that translate user gestures (mouse clicks, key presses) into messages. Web-based systems receive stimuli through HTTP requests and other interfaces. Smaller scale systems, such as objects inside a software application, expose Application Programming Interfaces (APIs) that define the set of methods to which internal objects and subsystems respond.

Result. A result is an effect that the system realizes in response to a specified stimulus in a specified context. A result may be either a message delivered to someone or something outside the boundary of the system or a change in the system’s internal state.

GUI systems deliver messages through forms, windows, screens, audio devices, and other output devices. Web-based systems deliver messages through HTTP responses and requests. An application’s internal objects and subsystems deliver messages through method calls and method return values.

In addition to delivering messages to external entities, systems also respond to events by recording information internally, and by making changes to that internal information. The information may be stored inside the running application, in a database, in files on the computer’s file system, or other storage mechanisms. The information that a system stores in order to guide its responses to future events makes up the system state.

Context. Sometimes a system’s planned response depends not just on information delivered through the stimulus, but other information as well. The context for a given responsibility is all of the information other than that delivered in the stimulus that influences the results that the system is obligated to realize in response to an event. The context may include information about the state of the system itself–that is, information that the system previously recorded in its internal memory about prior events. The context may also include information that the system can observe across its boundary–information that the system must request from external entities in order to fulfill the responsibility.

The idea of planned response systems is fundamental to how I think about programming and testing. I’m posting my thoughts here so that I can refer to these terms and ideas in later blog posts. Until I write those posts, I encourage you to notice what happens when you think about software systems as planned response systems.

A planned response system is a system that responds in planned ways to events in its environment.

For example, a software system is a planned response system—it responds in planned ways to users’ actions.

In an object-oriented software systems, each object is a planned response system—it responds in planned ways to messages sent by other objects.

Planned response systems produce two general kinds of results: They send messages to entities outside of the system boundary, and they make changes to the essential memory of the system.

An event is a significant change in the system’s environment. A change is significant to the system if the system is obligated to respond to the change in a planned way.

Events fall into two broad categories: Changes initiated by entities in the system’s environment (e.g. users or other systems), and temporal events caused by the passage of of time.

For example, an ATM is obligated to respond in a planned way to a user’s request to withdraw cash. The user’s request is an event.

A system responsibility is a system’s obligation to respond to each notification of a specified kind of event under specified circumstances by producing a specified set of planned results.

The specification of a system responsibility consists of three parts: A specification of a kind of event, a specification of a set of circumstances, and a specification of the set of planned results that the system is obligated to produce in response to being notified of an event of that kind under those circumstances.

A system becomes obligated to respond to an event when a system designer allocates that responsibility to the system.

The essence of a planned response system is the set of responsibilities allocated to the system, independent of the choice of technology used to implement the system.

The definition a system’s essence makes no mention whatever of technology inside the system, because the system’s essential responsibilities would be the same whether it were implemented using software, magical fairies, a horde of trained monkeys, or my brothers Glenn and Gregg wielding pencils and stacks of index cards.

One way to identify the essence of a system is to indulge in The Fantasy of Perfect Technology. Imagine a system implemented using perfect technology. Then ask yourself some questions about the quality attributes of the system.

How fast would it respond? If it were made of perfect technology, of course it would respond instantly, with zero delay. How many users could use it at once? An infinite number of users. How much information could it store? An infinite amount. How often would it break? It would never break. How long does it take to start up? None, because it’s always on and always available. How much energy would it use? It would use no energy; heck, it might even generate energy for free.

The one glaring flaw of perfect technology is that it does not exist. Real-world technology is imperfect. That’s what makes this exercise a fantasy. But it’s a useful fantasy, because it helps us to separate the system’s essential responsibilities from the temporary constraints of current technology.

Note that we apply the Fantasy of Perfect Technology only inside the boundary of the system. Even in our fantasy, the world outside of the system is made of real, imperfect stuff, with which the system will have to interact.

Now apply the fantasy to your own system. What responsibilities would your system have even if you could implement it using perfect technology? That set of responsibilities is your system’s essence.

The essential memory of a system is the set of data that the system must remember in order to fulfill its obligations—that is, in order to respond as planned to future events.

For example, an ATM must remember users’ account balances in order to determine whether to satisfy users’ requests to withdraw money.

A highly visible part of TDD is that developers write more tests than they used to. It is tempting to conclude from this that programming takes longer with TDD than without. After all, we are writing tests that we didn’t write before, and this is additional work on top of all the work we used to do. Right?

That’s a perfectly reasonable conclusion. But it is based on a flawed assumption, an accounting error that leads us to overlook some important costs. The assumption is that in addition to the new work of writing tests, developers will continue to do all of the same work they were doing before.

This assumption turns out to be unwarranted in practice. For example, before TDD, developers typically spend a great deal of time debugging. Why are they debugging? Because they have identified a failure, but they don’t know what specific piece of code is broken that produces the failure. They step through the code in the debugger in order to trace the failure to the fault. Only when they identify the broken code can they fix it.

TDD reduces the amount of debugging in two ways. First, developers write fewer defects. Second, when a developer introduces a defect, the code immediately fails one or more tests. These tests point directly toward the broken code. If the tests tell me what specific code is broken, I don’t need to run the debugger to find the fault.

Also, if developers write fewer defects, they now spend less time fixing defects.

If we add up all of the effects of TDD, including the cost of writing tests and the cost savings we gain by writing tests, we find that the first few features cost slightly more than without TDD, but that the quality is noticeably higher. And we find that later features take less time than without TDD, because TDD keeps code changeable.

An additional wrinkle leads to another accounting error: not everyone sees debugging as a cost. In my pre-TDD days, I usually enjoyed debugging. I loved having a meaty puzzle to solve. It was often the most fun and interesting and engaging part of programming. And in one job, my managers (falling prey to yet another accounting error) rewarded fixing bugs far more visibly and vocally than preventing them.

If you’re a manager, learn to attend not just to the obvious costs and benefits of a given set of programming practices, but also the costs and benefits that require a little effort and insight to detect.

If you’re a developer, I can tell you that I don’t miss debugging. The puzzle of how to choose the next test that will drive my code toward completion is as fun and interesting and challenging as debugging ever was. I hope it’s the same for you.

I teach classes about how to test software. Early in each class I describe testing as an information service. Even in classes filled with experienced testers, there are always a few people for whom this is a new idea.

In one class, just as I finished saying that testing is an information service, a man in the back of the room said, “Oh, no!”

“You disagree?” I asked.

“No, no, I agree,” he said. “It’s just that I’ve never thought of it that way before.” He paused and frowned. “And I think I’ve been doing it all wrong.”

I thought it was unlikely that he’d been doing it all wrong, so I asked, “How have you been doing it?”

“I just try to break stuff. When I can break it, it’s like I win. And if I can’t break it, I feel like I’m failing.”

“Trying to break stuff,” I said, “is an important part of testing.” I mentioned James A. Whittaker’s excellent book How to Break Software, which teaches testers how to find the kinds of defects that arise from common programming errors.

“I know,” he said, “but that’s all I’ve been doing. And when I find a nice, nasty bug, I run over to the developers and rub it in their faces.”

“Oh, no”, I said.

He laughed and nodded. “Now you understand.”

“How does that work out?” I asked. (I know what you’re thinking, but you’ve got it backwards. Doctor Phil channels me.)

“They hate it. And hate to see me coming. They keep telling me to bring them some good news once in a while.”

“But if your job is only to break stuff…”

“Then I never tell them what’s working. But that’s information, too, and that’s what I just realized. And that’s what they’ve been asking for.”

I’ve had numerous similar conversations with testers who had found themselves mired in unproductive relationships with developers. Shifting your focus from breaking stuff to informing stakeholders (including developers) can help with that.

I’ll say more later about testing as an information service. In the meantime, I’d love to hear your questions and comments about it.

So I tried something I hadn’t tried before: I interviewed my characters.

Well, that turned out to be more interesting than I’d anticipated. And it boosted my word count to boot. And on top of that, it offered some plot ideas.

I didn’t use any pre-planned questionnaire. There are zillions of character questionnaires on the web, and none of them ever seemed to get at the heart of the character.

Instead, I did what I do in many real-life interviews: Follow the energy. The idea is to:

1. Ask a question that invites the character to tell me something new
2. Listen for emotional intensity in the answer. Sometimes the emotion is subtle, and other times it’s big and obvious.
3. Ask my next question based on that emotion.

Rather than describing this process in detail, I’ll let you read the interviews as I conducted them, unedited. I offer these interviews not necessarily as exemplary, but merely as examples. The thing to notice is how I followed the characters’ energy.

Some background: The novel involves a time loop. Every 29 hours, the characters (and everyone else in the story world) loop back in time. The story follows two main plots.

In the first plot, Dan Roberge murders his wife Faith and her lover Zorem. Then time loops and he murders them again. And again. Police detectives Ray Andollo and Patty Yonce investigate.

The interviews:

• Dan Roberge
• Faith Roberge
• Zorem Bigotte
• Detective Ray Andollo
• Detective Patty Yonce

In the second plot, Amy Anderson saves her son from drowning in a pond on the family farm. Then time loops and her son drowns. Then time loops again. After the first incident (before the first time loop), Amy’s husband Frank becomes engraged when he discovers that Amy had been drinking while their sons played at the pond.

The interviews:

• Amy Anderson. This was my favorite interview, because it so significantly affected my understanding of the character.
• Frank Anderson