As we begin this episode, I’ve just created a fresh repository, and I’m ready to start developing my Towers game.

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.

Towers. Last year I developed Towers [PDF], a rectangular version of Kris Burm’s hexagonal game Dvonn. Now, Burm is a genius, and Dvonn is a fascinating game just the way it is, and the world doesn’t really need a watered-down rectangular version of it. But I wanted a board game to use as the basis for a sample application for my Test-Driven Development workshops, and hexagonal grids are just too much to ask of workshop participants. So Towers was born.

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?

In my previous post, I described how to write JUnit rules. In this post, I’ll describe some of the things rules are good for, with examples.

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.

JUnit rules allow you to write code to inspect a test before it is run, modify whether and how to run the test, and inspect and modify test results. I’ve used rules for several purposes:

• 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.

At the end of a workshop in 1997, I offered a clichéd end-of-training activity: “How will you use what you’ve learned in this workshop? Write that down.” A few people started to write. More people looked uncomfortable. More than half seemed to check out mentally, and two began to check out physically, gathering their belongings to leave.

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.”

The demand for certifications comes ultimately from hirers—in particular, from hirers who need to hire and retain highly skilled practitioners, and who are not themselves able to assess practitioners’ skills. Though certification programs may serve other needs, the hirers’ needs are the heart that pumps life into any certification.

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.

One of the most powerful things you can do to help someone solve a problem is to ask great questions. My new article ”Questions to Explore Problems” (PDF) gives dozens of questions that I’ve found essential in my work as a coach, including questions to explore:

• 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.

In a fascinating TED Talk, Laurie Santos shows that monkeys make the same kinds of economic errors as humans do. Another way to say this: Humans make some of the same kinds of economic errors as monkeys do.

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.

A few weeks ago, at Agile Development Practices West 2010 conference in Las Vegas, my friend and colleague Bob Payne hosted me for an episode of his Agile Toolkit podcast. I invite you to listen to our half-hour conversation and to other episodes about all things Agile.

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?