Exploration Through Example

Something I say about the ideal of Agile design is that, at any moment when you might ship the system, the code should look as if someone clever had designed a solution tailored to do exactly what the system does, and then implemented that design. The history of how the system actually got that way should be lost.

An equivalent ideal for TDD might be that the set of tests for an interoperating set of classes would be an ideal description-by-example of what they do, of what their behavior is. For tests to be documentation, the tests would have to be organized to suit the needs of a learner (most likely from simple to complex, with error cases deferred, and - for code of any size - probably organized thematically somehow).

That is, the tests would have to be more than what you’d expect from a history of writing them, creating the code, rewriting tests and adding new ones as new goals came into view, and so forth. They shouldn’t be a palimpsest with some sort random dump of tests at the top and the history of old tests showing through. (”Why are these three tests like this?” “Because when behavior X came along, they were tests that needed to be changed and it was easiest to just tweak them into shape.”)

I’ve seen enough to be convinced that, surprisingly, Agile design works as described in the first paragraph, and that it doesn’t require superhuman skill. The tests I see - and write - remind me more of the third paragraph than the second. What am I missing that makes true tests-as-documentation as likely as emergent design is?

(It’s possible that I demand too much from my documentation.)

One result of the technical debt workshop was that the attendees are more likely to talk about the code as an asset to preserve, improve, or destroy than as evidence of debt. See Mike Feathers on code as an asset or Chris McMahon on a project as an investment. Here’s my twist:

Consider a vegetable garden or a forest of pulpwood. The immediate value of either is what you get out of them at harvest time. That’s akin to the value a business gets when the deployed product gets used or a delivered product gets bought.

But there’ll be other harvests, and the way you prepare for this harvest affects the ones that follow. Over time, a well-tended garden gets better and better at growing vegetables (because the soil is looser, you’ve dug under organic matter, etc.). If you tend it poorly–just push seeds into the ground–it’ll never yield what it could.

Product code is like such a fertile asset: the programmers can tend it well or poorly as they prepare for release, and the result will only become obvious over time. The big difference is that the fertility of code varies a lot more than the fertility of a backyard garden. No matter how sloppily I treat my garden, I can’t ruin it as completely as sloppy, rushed coding can.

At the AA Functional Test Tools workshop, we had a little session devoted to this question: Even where “ordinary” unit test-driven design (UTTD) works well, acceptance-test driven design (ATDD) is having more trouble getting traction. Why not?

My notes:

1. Programmers miss the fun / aha! moments / benefits that they get from UTDD.
   1. Especially, there is a difference in scope and cadence of tests. (”Cadence” became a key word people kept coming back to.)
   2. Laborious fixturing, which doesn’t feel as valuable as “real programming”.
   3. No insight into structure of system.
2. Business people don’t see the value (or ROI) from ATDD
   1. there’s not value for them personally (as perhaps opposed to the business)
   2. they are not used to working at that level of precision
   3. no time
   4. they prefer rules to examples
   5. tests are not replacing traditional specs, so they’re extra work.

3. There is no “analyst type” or tester/analyst to do the work.

4. There is an analyst type, but their separate existence (from programmers) leads to separate tools and hence general weakness, lack of coordination

5. There’s no process/technique for doing ATDD, not like the one for UTDD.

6. ATDD requires much more collaboration than UTDD (because the required knowledge and skills are dispersed among several people), but it is more fragile (because the benefit is distributed - perhaps unevenly - among those people).

7. Programmers can be overloaded with masses of analyst- or tester-generated examples. The analyst or testers need to be viewed as teachers, teaching the programmers what they need to know to make right programming decisions. That means sequences of tests that teach, moving from simple-and-illustrative, to more complicated, with interesting-and-illuminating diversions along the way, etc.

Soap opera tests exaggerate and complicate scenarios in the way that television soap operas exaggerate and complicate real life. Jason Gorman describes something that happened to him that might have been caught by a soap opera test. (It shares the “upgrade happens in the middle of something else” property of the example at the link.)

A couple of years back, I lost my wallet on the way to an off-site meeting with a client.

I called my credit card company to ask them to cancel my card and send me a replacement. It just so happens at that very moment a replacement card was already on its way to me in the post because I’d been upgraded to a gold card.

They canceled the gold card. And didn’t send a replacement card because a replacement card was already on its way.

More on soap opera testing here.

Notes from a session at the workshop on Technical Debt. It was organized around this question: Consider two sets of Agile teams. In the first set, the teams do a fine job at delivering new business value at frequent intervals, but their velocities are slowly decreasing (a sign of increasing technical debt or a declining code asset). The other teams also deliver, but their velocities are all increasing. What visible differences might there be between the two sets of teams?

The following are descriptions of what’s unique about a typical decreasing-debt team:

• Most of the team produces 98% clean code all the time, but there is some untidiness (whether due to lack of knowledge, lack of effort, or whatever). However, one or two people take one or two hours a week doing a little extra to compensate. (Chet Hendrickson)

• Behavior in relation to the code is not apprehensive. They’re not scared of the code they’re working on, they’re not afraid of making mistakes that break the code base. (Michael Feathers)

• They’re frequently talking about the state of the code. There are many give-and-take technical discussions. They might be heated or not, but participants are always alert and engaged. The content is more important than the tone: they are discussing new things rather than rehashing old issues. The ongoing conversation is making progress. (Many)

• There are no big refactorings; instead, there are many small ones. (Ron Jeffries?)

• No code ownership. (I forget)

• Time is spent on building affordances for the team’s own work. In Richard P. Gabriel’s terminology, they spend time making the code habitable: the code is where they live, so they want it to be livable, put things where they are easy to find, make them easier to use next thing. (Matt Heusser and others)

This isn’t a complete list, only the ones that struck me and that I remembered to write down.