Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Tue, 19 Dec 2006

Lively wireframes

Tests are better than requirements documents because they're more lively. Not only do they describe what the system is to do, they give strong hints about whether it does it. Requirements documents just sit there. The liveliness of tests makes up for the occasional awkwardness of their descriptions. (It's harder to write for two audiences—the human and the test harness—than it is to write for one.)

In a series of talks I gave earlier this year, I described three types of business-facing tests: ones based on business logic, ones based on workflow, and ones based on wireframe mockups of a user interface. I talked about wireframes last, and what I had to say compared poorly to the previous two. Those tests had been simultaneously executable and OK-to-good at communicating. But, when it came to wireframes, the best I could do was draw one on a flipchart and say, "I wish I could lift that off and put it in the computer. The closest I can come is this..."

BAD:   def test_structure_without_audits_or_visits     wireframe_looks_like {       page.has_two_columns.and_all_forms_use_the_session_id.                            and_all_links_use_the_session_id_except_help         page.title.has_id(:patient_display_page).                  and_includes(:current_animal).                  and_includes(:current_client)         page.main_text.has_no_list_named(:visits).                      has_no_list_named(:audits).                      has_a_form_with_action(:want_add_visit_form).                      has_a_form_with_action(:want_add_audit_form).                      has_a_help_popup_named(:patient_display_page).                      and_no_other_actions     }.given_that {       a_user_is_logged_in       an_animal_has_been_selected       the_animal_has_no_visits       animal_treatments_have_never_been_audited       there_is_help_for_page(:patient_display_page)     }   end

That's bad because we have two separate representations, each of which is lousy for one of the two audiences. I now think I have something better. Here's a wireframe:

It's a drawing created with OmniGraffle Pro (using a stencil from John Dial). That kind of wireframe is easy for a whole team to talk about, but it's too ambiguous for a testing tool. (How would it know whether a given rectangle is a text box, a text field, or the decoration at the bottom of the window?) Fortunately, Omnigraffle allows you to attach notes to graphics. The yellow tooltip-ish rectangle shows annotations to a text field that remove ambiguity.

Here's a test that uses that wireframe:

The image is just there for human consumption. In real life, I'd want the human to work exclusively on the Graffle document and not think about PNG files at all. Instead, I'd have a script watch for changes to Graffle files and regenerate all the PNG images.

The actual test ignores the image. Instead, it parses the Graffle file ("normal-run.graffle"), hooks the program up to a fake window system that records messages like setStringValue and selectAll, starts the program, waits for it to do all its UI initialization, then compares the state of the windows against what the Graffle document claims. When the tests run, the results look like this:

The error messages could do a better job of pointing to the right control, and it's a shame that the image doesn't appear in the output. (Fit swallows it along with any other HTML tags in the test input. No doubt I could work around that.) However, this output is only for programmers already deep in the code. It doesn't have to be as friendly as output aimed at a wider audience.

I still have two big open questions.

• How much time would it take to make a fake window system that could maintain all the state anyone cares to express in a test? (And what is it that should be expressed in such tests? I'll have more to say on that later, probably.)

• How fragile will these tests be in the face of change? Updating the annotations and the tests has to be a small part of changing the wireframes and the UI code.

The next installment ties this into the Atomic Object style of model/view/controller, as described here (PDF) and in a forthcoming Better Software article. But first, I have to figure out how to parse canvases out of Graffle files. And there's that whole vacation thing.

## Posted at 21:50 in category /fit [permalink] [top]

Wed, 13 Dec 2006

Best signature ever

Plucked from the bottom of mail from Pete McBreen:

"For a list of all the ways technology has failed to improve the quality of life, please press three." - Alice Kahn

## Posted at 12:26 in category /misc [permalink] [top]

Tue, 12 Dec 2006

Primary Loyalties

This is an editorial that expanded on an offhand earlier post. It was rejected. While it does have two potentially offensive analogies, I figure I have more leeway in what I publish here. It's had a postscript added and is now filled with hyperlink goodness.

A recent UN report states that "New explosive devices are now used in Afghanistan within a month of their first appearing in Iraq." (Reuters, September 27, 2005). Compare that to the rate of diffusion of technology in our field. I'll use continuous integration as an example. It's a well-established technology that's easy to deploy, is practically without risk, has considerable benefit, was first widely described in 2000, and has had a solid open source tool supporting it for at least three years. But there's a reasonable chance you've never heard of it. (Note: true of original audience; likely not true of this blog's audience.) If you tried to deploy it, it might well take months and months to get permission, to round up a build machine, and to get the first people using it.

Something is desperately wrong with this picture. Why is it that people living in isolated harsh conditions where people are trying to kill them can move faster than we can in our offices?

John Robb, a software executive and former Air Force counterterrorism operative, describes what the guerrillas do as open-source warfare, and he's developed a rather elaborate theory of how that works. One underpinning of the theory is what he calls primary loyalties. "A primary loyalty is a connection to a non-state group that is greater than loyalty to a state. These loyalties include those to clan, religion, tribe, neighborhood gang, etc. These loyalties are reciprocated through the delivery of political goods [...] by the group that the state cannot or will not deliver."

Professional-class employees like you and me once had something like a primary loyalty to our employer, especially if it was a large company. In the US and elsewhere, that employer delivered "goods" to us like steady employment, guaranteed pension, medical care, a career path, and the training we needed to advance along it. Under Anglo-American capitalism, at least, corporations no longer deliver many of those things. Instead, as is described in Jacob Hacker's The Great Risk Shift, companies have given us the opportunity and responsibility to provide those things for ourselves. For example, instead of being given a guaranteed pension, we're given money to invest. If we invest well, we'll end up with more retirement money than the pension a company would have given us; if not, well, tough luck.

Whether that's a good or bad shift, employees have acted like people in Iraq and other failed states: they've shifted their primary loyalty elsewhere. In the US, we've seen rising nationalism, increased devotion to religious groupings, and more loyalty to political "tribes" (though not increased formal party membership). None of those loyalties have anything to do with work. Therefore, according to Robb, we're missing a key part of the infrastructure that supports fast diffusion and implementation of technologies at the office.

I think that's bad. We need groups that deliver the goods and are deserving of loyalty. Existing structures (unions, professional societies) aren't working, and I'm loathe to wait for them to start. The best I can offer is the autonomous team. I'm not talking about collections of individuals who've sleepwalked through "team-building exercises," but actual teams that work together very closely (often in pairs), learn together quickly, and provide cover for each other. When a team is working, the business comes to view it as a single specialist, a unit, with authority over what happens within itself. If the team decides to try continuous integration, it will deploy it without ever thinking to ask permission.

I acknowledge that it's offensive, at some gut level, to suggest emulating killers. But if this decade has a notable example of the "learning organization", it is—sadly—groups of insurgent cells with high internal loyalty and loose connections to both each other and also to the overarching sources of goals and funding.

P.S. John Robb's ideas haven't convinced me yet—sometimes his analogies seem more than a bit strained—but you may find his site worth a read. Hacker's notion of a risk shift has also drawn some scorn, though that particular link misses the point that matters to me. If you're an investor in the stock market, you expect stocks with higher volatility to pay higher returns over time. The higher returns are your payment for accepting higher volatility, usually tagged as "risk". What I take from Hacker is that a career today has higher volatility than in the past, but that higher risk has not come with significantly higher returns—instead, the US real median income has increased by 31% from 1967 to 2005 (source, PDF, p. 5). That's an annual real return of 0.6%. For comparison, that's a bit less than the real return on short-term US Treasury bills, historically the world's least risky investment.

## Posted at 07:53 in category /misc [permalink] [top]

Mon, 11 Dec 2006

Humbling

My wife is writing the chapter on mammary gland health and disorders for Large Animal Internal Medicine, a standard reference. Her current draft is 119 double-spaced pages. It has 532 citations. The scary thing is how much she remembers—off the top of her head—about the contents of the papers. She is truly a fox.

Me, I can barely remember the difference between Facade and Adapter.

## Posted at 14:14 in category /misc [permalink] [top]

Thu, 30 Nov 2006

Did I say "Scripting for Testers"?

Scripting for Testers has been renamed Everyday Scripting in Ruby because a couple of reviewers argued that pretty much all that was required to make it suitable for a larger audience was changing the title and the bit of Introduction that says who the book is for. So we did.

I hope testers still pick it up. The subtitle says "for teams, testers, and you", which helps Google find it when you type in "scripting for testers." (It's the top hit.)

Sadly, the scheduled ship date is a bit after Christmas. Since it would be sad if testers didn't get the book under their tree, we've decided to delay the holiday.

Thanks to those who helped me on it: Mark Axel, Tracy Beeson, Michael Bolton, Paul Carvalho, Tom Corbett, Bob Corrick, Lisa Crispin, Paul Czyzewski, Shailesh Dongre, Gunjan Doshi, Danny Faught, Zeljko Filipin, Pierre Garique, George Hawthorne, Paddy Healey, Andy Hunt, Jonathan Kohl, Bhavna Kumar, Walter Kruse, Jody Lemons, Iouri Makedonov, Chris McMahon, Christopher Meisenzahl, Grigori Melnik, Sunil Menda, Jack Moore, Erik Petersen, Bret Pettichord, Alan Richardson, Paul Rogers, Tony Semana, Kevin Sheehy, Jeff Smathers, Daniel Steinberg, Mike Stok, Paul Szymkowiak, Dave Thomas, Jonathan Towler, and Glenn Vanderburg.

UPDATE: People have pointed out the lack of links. I am a master of Marketing.

• The book's home page.
• Amazon
• Barnes and Noble
• O'Reilly
• Powells

## Posted at 06:47 in category /misc [permalink] [top]

Open Office for Fit

I've started using OpenOffice (in its Mac-ified NeoOffice form) for writing Fit tables. It's working considerably better than Word. Not only does it produce decent HTML (valuable when you're trying to figure out exactly what's going on), it does a better job of producing an HTML file that looks similar to the original WYSIWYG editor view, both when displayed through a browser and when read back into the editor.

I should note that I'm still using Word X for the Mac, so others might have better luck with Word than I've had. But if Word isn't working well for you, check out OpenOffice.

## Posted at 06:47 in category /fit [permalink] [top]

Fri, 10 Nov 2006

Nerd humor

These are all mentioned in Crypto-Gram.

First, the recent torture-lite bill boiled down to C code.

if (person = terrorist) {             punish_severely(); } else {             exit(-1); }

There's more than one relevant bug. More here.

Next, check out the comments to A Million Random Digits. I like B. McGroarty's best.

Next, 19 Year Old Diebold Technician Wins Us Presidency.

## Posted at 14:29 in category /misc [permalink] [top]

Wed, 01 Nov 2006

IEEE Software issue on TDD

IEEE Software will have a special issue on test-driven development (May/June 2007). I'm a reviewer, and I've been asked to spread the word. The Call for Papers is here. The deadline is December 1.

## Posted at 07:53 in category /misc [permalink] [top]

Response to an essay

At OOPSLA, I was tapped to give the response to Jim Waldo's essay, On System Design. The essay isn't online yet, so here are what I see as its main points:

• Almost all systems have designs. Most are bad. Some are good. (There is some tension in the essay about the word "design". It sometimes feels like design is inherent in the system, sometimes like it requires a description of the system, and sometimes that it is an act performed with a certain attitude over a prolonged period of time.)

• There is no single design method, though conversation and thoughtful reflection and iteration seem to be required. Good design comes from good designers. Design is learned through apprenticeship.

• Design was more possible in the past. (The essay does a nice job of listing the forces working against design.)

• All is not lost, though. Open source allows people to learn system design by examining designs, and it evades some of the forces that work against design. Agile software development has the conversations and iterations characteristic of the design process.

• Designers must have the courage to push back against the forces pushing against good design.

Unusually, for me, I wrote my talk down as an essay and read it to the audience. (Bad idea—my first flop sweat experience in a long time.)

My job is to give a thoughtful reaction to this essay, to describe what it means to a person with my perspective. Here goes.

You've just heard a description of a fall from a Golden Age when the world allowed us our values—to a world where the people and structures that hold power over us are disinterested, immune to our influence, and unwilling to leave us to putter in peace, despite our heartfelt claims that we'd all be better off if they did.

We're not the first people in this situation—many have been in far worse—and as I reread Mr. Waldo's essay one day, I thought it might be instructive to see how those others have handled it.

One response, the default perhaps, is despair and retreat from engagement. I think we're all familiar with that feeling, and with those who've succumbed to it, so I won't discuss it further.

The next two responses come from the Hellenistic period of Greek history, which followed the Classical period and was a time of turmoil, during which you might easily and uncontrollably go from great wealth to poverty or from power to slavery. This raised the practical question: how do you make yourself happy in a hostile world?

Zeno of Citium's answer has come to be called Stoicism. In this tradition, happiness comes from the possession of the genuinely good, and the only things that are genuinely good are the characteristic virtues of humans: wisdom, justice, temperance, courage, and so forth. We might include the desire to apprehend elegance in design as a virtue.

The wise person—the happy person—makes decisions based on how they align with the genuinely good. The results of those decisions have nothing to do with happiness: the Stoic would prefer they lead to wealth, health, and life, but is ultimately indifferent if they lead instead to poverty, sickness, and death. Epictetus puts it this way:

Our opinions are up to us, and our impulses, desires, aversions--in short, whatever is our doing. Our bodies are not up to us, nor our possessions, our reputations, or our public offices... if you think that [those] things ... are your own, you will be thwarted, miserable, and upset, and will blame both the gods and men.

From this, we get the popular image of the Stoic as someone who does what's right, because it's right, and is immune to attempts to sway her through non-rational emotions like fear of death. Marcus Aurelius, a later Stoic, put it this way:

Say to yourself in the early morning: I shall meet today ungrateful, violent, treacherous, envious, uncharitable men... I can [not] be harmed by any of them, for no man will involve me in wrong.

The Stoic approach to our problem would be to do thoughtful design because it is a good, and to be indifferent to the consequences. We would, for example, not care if the only company that would allow us to design well pays poorly, builds mundane software, and has no free soda in the kitchen. Stoicism is, I believe, what Mr. Waldo advocates.

But Stoicism was not the only philosophy that sprang from the chaos of the Hellenistic period. Epicurianism was another.

This is Epicurus, the founder of Epicurianism. In Epicurianism, happiness means having your desires satisfied and pain avoided. The virtues—courage, wisdom, and the like—are useful because they lead to the satisfaction of desires, not in and of themselves (as in Stoicism).

The best strategy toward happiness is to pare your desires down to the minimum, which are then easily satisfied. One should avoid desires that are inherently unlimited, such as those for wealth, power, fame, and the like, in favor of desires that can be readily satisfied—by, say, filling your stomach when hungry. Moreover, simple food is easier to obtain than fancy food and fills the stomach just as well; therefore, you should strive to be happy with simple food, though equally happy to eat fine food when it's there.

When I think of Epicurianism today, I think of the open source programmer who comes home from an unsatisfying job and spends part of the evening working on Firefox plugins or Ruby packages, designing them to meet the highest standards. Since, to Epicurus, current pain is outweighed by the mental pleasure of remembering past pleasures and anticipating future ones, the next day at work is thus made tolerable.

A third reaction is, to a Western audience, most associated with the period after the stability of the Roman empire collapsed. It is a negotiated retreat from the field of battle.

Here is a monastery. I suspect that it was built on the edge of a cliff not because of the view but because that's a defensible location.

Monasteries had defenses because they were liable to attack. Many of the attacks were like those of the Vikings on England, Ireland, Scotland, and elsewhere. Those attacks came from outside the existing, fragile social order. But there were also attacks from closer to home. A record that spans the 1400s shows that monasteries in Ireland had troubles long after the Vikings ceased to be a threat:

1394: The monastery of Loch Seimhdille was burned by the family of Ó Ceallaigh thirty-one years after it had been previously burned by Cathal Óg Ó Conchobhair.

1398: Mac Diarmada of Magh Luirg, ..., went to provision Carraig Locha Cé and compelled the monastery of Boyle to supply Carraig.

1402: A foray by Ó Ceallaigh and Clann Chonnmhaigh on the monastery of Comán.

This being roughly a thousand years after Christianity reached Ireland, but before Martin Luther, I'm speculating here that these attackers were Catholic Christians, yet they were not deterred by the presumed anger of the Christian God at attacks on His monks. Hence: walls, cliffs, and towers to which the monks could retreat while the raiders plundered.

Still, the monks did not simply disappear from society behind walls. They provided value to those they'd left behind.

For example, they would pray for the souls of your departed relatives.

And monasteries were a convenient place to stash the still-living bodies of inconveniently undeparted relatives. The picture is of Sophia, inconvenient to Peter the Great, in a nunnery.

And, of course, in Belgium there was beer.

I am sure these services gained them some protection.

When I think of monasticism today, I think of Agile projects. In Agile projects that are running well, there is an implicit or explicit deal between the team and the business. The team promises to deliver shippable business value at frequent intervals and not to whine when the business changes its mind about what it wants. In return, the business leaves the team alone to build the product as they like. That allows people who crave good design to do it—provided they can mesh it with the need to deliver frequently. In practice, that means that code becomes the whiteboard on which the design is discussed, rediscussed, and refined. This—in the best cases—seems to me exactly the same process Mr. Waldo describes. By that, I mean that the attitudes of people toward the design are the same, the conversations have the same air, the values informing the conversations are the same, and the code—in roughly the same time frame—comes to have as satisfying a design.

I claim the monasticism of the Agile project is a more sustainable model than Stoicism or Epicurianism. It requires less of us because we get to lean on each other. Even programmers, notoriously not team players, gain strength from each other.

Perhaps that's a claim we can discuss.

For my part, I've recently become obsessed with the weakness of Agile Monasticism. Here is a story I heard from an ex-employee of a company I'll call Frex:

[That] year came dreadful fore-warnings over the land of [Frex], terrifying the people most woefully: these were immense sheets of light rushing through the air, and whirlwinds, and fiery dragons flying across the firmament. [By this, he refers to the acquisition of Frex by a larger company.] These tremendous tokens were soon followed by a great famine [the new head of marketing moved the Customer out of the project team room] and not long after, on the sixth day before the ides of January in the same year, the harrowing inroads of heathen men [a new VP of Development] made lamentable havoc in the church of God in Holy-island by rapine and slaughter. [The imposition of a "more mature" development process caused all but one of the team to quit.]

Such stories are common. Agile projects have no real defensive walls; all they can do is deliver return on investment and hope the business values it. But we all know that ROI is only a part of what moves businesses. Those in the Agile world all know of resistance to Agile from those middle managers who see it as a threat to their power to command and control. Telling such a person that her sabotage endangers the company's ROI is like an abbot standing in the path of Christian raiders and threatening them with loss of their immortal souls: sometimes it works, but nowhere near often enough. And it never works with the worshippers of Odin.

The universe of Agile teams is like a school of fish. Every once in a while, a predator sweeps through us, grabs a team in its mouth, and destroys them. We flail around in panic for a few moments, talk about the stupidity of it all with our nearest neighbors, then reform as before, ready for the next predator.

This is—I repeat—still better than before. Teams do tend to protect their members. Testers are less likely to be offshored. Those who obsess about design can do it without justifying themselves to the unsympathetic. But the teams themselves, as wholes, have no structure of protection.

Mr. Waldo's essay, paradoxically, is leading me to seek answers to the current problems of Agility in collective action exactly because its focus on individual courage calls attention to our biggest blind spot: we believe that each of us must alone contend against aggregates possessing decades of institutional power. We don't even think about standing shoulder to shoulder.

What path we should take, I don't know. Unionism is so foreign to the professional class in the US that I'm nervous about admitting I've ever even had the word in my mind. The ACM appears to me an organization for extracting money from people in return for papers printed in 9-point type, papers placed in bibliographic categories that don't seem to have changed since the seventies. Neither it, nor the IEEE, have enough spunk. The Agile Alliance, on whose board I sit, doesn't seem to have the right leverage. So I don't know what we should do, together, but I'll be thinking on the problem, and that's because of On System Design.

Credits

Special thanks to Donnchadh Ó Donnabháin, who tutoried me in Gaelic pronunciation.

## Posted at 07:47 in category /agile [permalink] [top]

Tue, 24 Oct 2006

Wanted: sound file

My life would be ever so much better if I had a snippet of the ka-chunk sound that a 35mm slide projector makes when changing slides. Anyone got one or can record one?

Update: My life is ever so much better. There are at least three people in the world much better at Google than I am. Thanks, all.

Update: I've gotten requests for what I used. Here it is: http://freesound.iua.upf.edu/tagsViewSingle.php?id=4868. It uses a Creative Commons license.

## Posted at 14:49 in category /conferences [permalink] [top]

Gaelic pronounciations needed

For a mini-talk I'm giving at OOPSLA and possibly part of later talks, I probably need acceptable pronunciations of Gaelic words. I tried Gaelic pronunciation guides I found on the net, but what I'm coming up with can't be right. Here are the words. Do you know how they're pronounced? (Send a description or, better, a sound file.)

Comán (Koe-mahn)

Chonnmhaigh (Chawn-way, where "ch" is as in "loch". Is it really pronounced as strongly as a "ch" at the end?)

Ceallaigh (Kallagh, where "gh" is like the "ch" in "loch" but based on a G - whatever that means.)

Seimhdille (this is where I gave up - I can't figure out anything for that combination.)

Cathal

Óg (that's with a long o, right? So it's pronounced like the first two letters of "ogre".)

Conchobhair

Diarmada

Magh

Luirg

Carraig

Locha

Cé (Kay?)

Update: A Gaelic speaker will be teaching me the right pronunciation at OOPSLA before my talk. Isn't that cool?

## Posted at 14:48 in category /misc [permalink] [top]

Thu, 19 Oct 2006

The learning organization

A recent UN report states that "New explosive devices are now used in Afghanistan within a month of their first appearing in Iraq." (Reuters, September 27, 2005). How long does it take your organization to put a new technology or technique into use? How does that make you feel?

Offensive though it is, this decade's most notable examples of "learning organizations" are groups of insurgent cells with high internal loyalty and loose connections to both each other and also to the overarching sources of goals and funding.

## Posted at 05:06 in category /misc [permalink] [top]

Tue, 17 Oct 2006

A fixture for Boolean-valued business logic

I've implemented the fixture described earlier. It takes a table in a particular format, generates a new ColumnFixture table, and causes that table to be executed. You can see the Fit output a programmer works with here.

The source and jar file are at http://www.exampler.com/testing-com/tools/fitlibrary-extensions-0.1.zip. The README.txt file will tell you about examples.

I believe it works correctly, and I put it to the test at a client's on Monday. Nevertheless, it is an early version: I made no attempt to handle malformed input gracefully. I haven't made it work with DoFixture yet. I need to clean up the source directory structure. (JUnit tests are intermingled with source files.) I realize that the fixture knows almost enough to generate much of the ColumnFixture code for you, so I'm going to add that.

The version in the zip file was compiled under Java 1.4, though it is likely to compile under earlier versions.

## Posted at 16:57 in category /fit [permalink] [top]

Mon, 09 Oct 2006

An OOPSLA tutorial

If you're going to OOPSLA, I recommend you attend the tutorial Programmers are from Mars, Customers are from Venus: A Practical Guide to Working with Customers on XP Projects. I haven't taken it myself (never been in the right place at the right time), but I've talked to the lead presenter, Angela Martin, at length about the topic, and she's given me the complete notes. For those who don't know of her, Angela is one of the first names that springs to mind when you think about customers / product directors / product owners. Not only does she have practical experience, but she's also done some extremely interesting anthropological-ish research. Her co-presenters are Robert Biddle and James Noble, who have quite a good reputation as presenters. (Their postmodern programming presentation a few years back is a classic, a St. Crispin's Day event.)

I mention this because the description at the OOPSLA site has two flaws. "Working with Customers on XP Projects" in the title makes it seem that it's not for Scrum projects, but it is. And the blurb does not say, "This is for you too, programmers." From Angela's description, it most emphatically is.

## Posted at 09:02 in category /conferences [permalink] [top]

Thu, 28 Sep 2006

Off the rails

I'm too sick to write what I should be writing, and I can't sleep, so I decided to collect my thoughts and references about a current political topic I've been studying as I have time. The normal sort of posts will return shortly, but for the moment I'll use whatever reputation I have for careful-but-sympathetic thought to push back against an all-but-inevitable failure.

My understanding is that habeas corpus is a method by which prisoners can challenge their imprisonment before a judge. The idea has worked pretty well for 700 years. It fits with John Adam's phrase "a government of laws, not men": no one has exclusive power; everyone is subject to being checked and balanced.

It is now due to be removed in a hastily-considered bill. Despite what some say, the idea of habeas is not to "give terrorists rights"; it is to preserve the rights of those wrongly accused as terrorists or unlawful combatants. There have been many such people already. Sometimes people are just detained; some are sent to Syria and tortured.

The bill allows for review of detentions by military commissions, but to date only ten have been held. People can be held forever without any recourse. (Some people have continued to be held even after review found them innocent, though a large number have been released.) In newer versions of the bill, "people" can include US citizens. Unlike the military's current definition of unlawful combatant, which covers only "those who engage in acts against the United States or its coalition partners in violation of the laws of war and customs of war during an armed conflict," the new one covers anyone who "has engaged in hostilities or who has purposefully and materially supported hostilities against the United States" or its military allies. Who are our allies? What does "material support" mean? I guess some of us might just find out.

During detention, what? It is simply not the case, as the President stated, that Geneva Convention Common Article 3 is impossibly vague about the treatment of prisoners. Ironically, on the same day as that statement, the US military released its new procedures, which explicitly conform to the Geneva Conventions. It's not surprising that, in over fifty years, we've been able to come to agreement about what the Conventions require. But now we're going to replace them with new language that will have to be freshly interpreted. Everyone, save the people who'll actually be making the decisions—who refuse to commit themselves—is running around saying "waterboarding is allowable" or "waterboarding is not allowable", but that's silly. In the absence of court review, what's allowable is whatever's done. The legal principle is that "there is no right without a remedy."

The pros apparently don't think torture is effective:

I am absolutely convinced [that] no good intelligence is going to come from abusive practices. I think history tells us that. I think the empirical evidence of the last five years, hard years, tell us that. . . . Moreover, any piece of intelligence which is obtained under duress, through the use of abusive techniques, would be of questionable credibility, and additionally it would do more harm than good when it inevitably became known that abusive practices were used. And we can't afford to go there.

Some of our most significant successes on the battlefield have been -- in fact, I would say all of them, almost categorically all of them, have accrued from expert interrogators using mixtures of authorized humane interrogation practices in clever ways, that you would hope Americans would use them, to push the envelope within the bookends of legal, moral and ethical, now as further refined by this field manual.

We don't need abusive practices in there. Nothing good will come from them.

(From the announcement of the new procedures, above.)

But there's no institutional check on the non-professionals or the rogue professionals. We'll just have to rely on the moral character of everyone involved. That's of course entirely opposed to the American tradition of rule by laws, not men, but <sarcasm> apparently we face a threat more grave than the 45,000 nuclear warheads the Soviet Union had at its peak and a struggle more threatening than World War II, and so cannot afford the traditions that have worked for more than two hundred years </sarcasm>.

We certainly face threats—always have, always will—but I don't see any reason to give into the "this time it's different" fallacy.

All this matters to me because my parents grew up in Nazi Germany. I grew up knowing that cultures can descend into madness, and that it can happen without the majority ever really explicitly willing it or being really conscious of it. No, I'm not saying that America is just like Nazi Germany; I'm saying that men like my grandfather—not politically involved, just trying to live their lives—somehow, through fear or anger or depression or just passivity, let decency slip out of their grasp.

It also matters because I grew up knowing that the Americans were the good guys. My father (in the German Navy) was captured near Marseille. He didn't mind; he and his fellows didn't fight back. They wanted out of the war, and they wanted to surrender to the safest force: the Americans. Prisoner of war camp (American and French) was no picnic—my father weighed 130 pounds when he got out—and there was abuse, but it was not institutionalized (except in one camp, for a short time). He got what he expected, and he believes he has no cause for complaint.

In contrast, my Uncle Paul was captured by the Soviets on the eastern front. I imagine he fought harder than my father to avoid capture, because everyone knew what happened to Russian prisoners. And it did happen: it was 1950 before he even knew the war was over, and he came home broken for life.

There's practical value to being seen as the good guys, the just guys, the humane guys. That's not just true when fighting Germans; it works in the middle east, too.

Out of fear or anger or depression or just passivity, we're letting our elected representatives—our employees—reinforce hysteria to no effective end. If that bothers you, here is your Senator's contact information, and here is your Representative's.

Although this bill is being pushed by Republicans, I believe it should not be a partisan issue. The bill does not square with the conservative tradition of Chesterton's gate. It's being rushed through because what being a Republican politician today means is all about winning at domestic politics. (Just as being a Democratic politician appears to be all about not losing.) I can echo the the author of this fantastic essay: I miss Republicans. I miss Eisenhower; he'd surprise you.

## Posted at 00:09 in category /misc [permalink] [top]

Wed, 27 Sep 2006

More on boolean expressions

My examples below use a simple rule for deciding what values of a boolean expression to test. I should probably describe it and justify it.

Given an expression with all ands like X1 and X2 and ... and Xn, you use these test values:

1. One case: all the Xi's are true.

2. N cases. In each, all the Xi's are true except for one that's false. (A different one every time.) The way I think about it is that, for each Xi, there's an example that shows the whole expression is false exactly and only because of it.

So the table for (A and B and C) would be this:

The case for or-expressions is similar: just flip all the trues and falses:

The reasoning behind these rules is based on mutation testing, the name for a long thread of academic research on testing. The way I state it (which is different in an unimportant way from how it's usually put) is that mutation testing involves assuming that the code is incorrect in some definable way, then asking for a test suite that can distinguish the incorrect code you have from the correct code you should have.

Now, for any given program, there are an infinite number of variants, so mutation testing depends on picking a definition-of-incorrectness that (a) lets you generate a reasonably small set of alternatives, but (b) gives you confidence that you've caught all the plausible errors. The usual approach is to assume one-token errors.

For example, suppose you are given (A and B or C). Maybe it should be (A or B and C) or (A and not B or C) or (A and (B or C)).¹

One-token errors aren't the only ones you could make. For example, you might completely forget that D ought to be involved in the expression—it should be (A and B and C and D). That's a fault of omission, and mechanical techniques aren't good at them. Nevertheless, one-token errors seem to work pretty well for boolean expressions.

Suppose you have the original (A and B or C) and a variant (not A and B or C). The test value (A=true,B=true,C=true) distinguishes the two, because the given expression yields true while the possibly-more-correct variant would yield false. So, when you run the original program and its variant², that test case will produce one answer in the original and a different one in the variant. One of them's got to be wrong. If it's the original program, you've found a bug. If it's the variant, you know that variant cannot be the correct program (the original is not incorrect in that way). In the jargon, the mutant is killed.

Trying all the possible combinations of variable values will either find a one-token error or kill all the mutants. But you never have to try all of them. There will be some test inputs that don't add anything: any mutant they kill will be killed by some other test input. So you can construct a minimal set for any given expression.

If you look at the table below, you can see that the rule for and-expressions I gave above is justified; the cases I give kill all the mutants. (In the table, the first row is for the expression as given; each row below it is a mutant. The X's in a cell means that column's test case kills that mutant.)

Remember all this assumes that tests powerful enough to catch one-token errors will catch more complicated (but still plausible) errors. A way to convince yourself is to try and find a variant of (A and B and C) that won't be caught by these test cases. Ask yourself if it's at all plausible that you'd make such an error. (Remember: we've already conceded faults of omission.)

These rules are easy to memorize. The cases for expressions that mix and and or are not. A long time ago, I wrote a program that generates probably-minimal test sets for any given boolean expression (including relational operators like a<b). Timothy Coulter and Curtis Pettit, students of Cem Kaner, made it more capable and gave it a web UI. Here it is: http://www.oneofthewolves.com/multi/applet.html.

When using the style I described earlier, I don't think you need multi, because I'm tentatively advocating always breaking tables that combine ands and ors into separate tables that do not.

¹ I can't remember if the transformations I used when working all this out included substituting one variable for another (like (A and B and A)). Multi, described after this footnote, doesn't. I don't think it would make a difference—certainly it doesn't in this particular example—but I'm not going to bother to check.

² I'm leaving what it means to "run a program" vague. That gets to the difference of whether the mutation is "weak" or "strong". See this post by Ivan Moore. I didn't find much in the online literature about mutation testing; if you want to know more, you'll have to go to the library. There are some starting references at the end of this paper (PDF).

## Posted at 08:36 in category /fit [permalink] [top]

Sun, 24 Sep 2006

Describing yes/no choices in Fit

Using Fit to describe boolean (yes/no) decisions can be much clearer if you just insist that all decisions be expressed in multiple, uniform, simple tables. No boolean expressions in the code may mix ands and ors, but that's not a bad idea anyway in this age of small methods and ubiquitous languages.

Suppose you're given a jumble of three packs of cards. You are to pick out every red numbered card that's a prime, not rumpled, and is from either the Bicycle pack or the Bingo pack (but not from the Zed pack). Here is a way you could write a test for that using CalculateFixture:

I bet you skimmed over that, read at most a few lines. The problem is that the detail needed to be an executable test fights with the need to show what's important. This is better:

That highlights what's important: any card must successfully pass a series of checks before it is accepted. This test better matches what you'd do by hand. Suppose the cards were face down. I'd probably first check if it were rumpled. If so, I'd toss it out. Then I'd probably check the back of the card to see if it had one of the right logos, flip it over, check if it's black or a face card (two easy, fast checks), then more laboriously check if it matches one of the prime numbers between 2 and 10 (discarding Aces at that point).

The code would be slightly different because it has different perceptual apparatus, but still pretty much the same:

It does bug me that the table looks so much more complex than the code it describes. It still contains a lot of words that don't matter to either the programmer or someone trying to understand what the program is to do. How about this?

From this, the Fit fixture could generate a complete table of all the given possibilities, run that, and report on it. (Side note: why did I pick Queen as a counterexample instead of Jack or King? Because if the program is storing all cards by number, the Queen will be card 11. Since I'm not going to show all non-primes—believing that more trouble than it's worth—I should pick the best non-primes.)

The same sort of table could be created for cases where any one of a list of conditions must be true.

Now, many conditions are more complicated than all of or none of or any one of. However, all conditions can be converted into one of those forms. Here's an example.

Suppose you're allowed to pay a bill from an account if it has enough money and either the account or the "account view" allows outbound transfers. That would be code like this:

However, that could also be written like this:

I claim that code is just as good or even better. It's better because there's less of a chance of a typo leading to a bug (writing a && b || c instead of a && (b || c)). It's also arguably better because a new word and perhaps idea have been introduced into the project language: "money source". I think finding the right words is often important.

The corresponding tables would be like this:

In this particular case, I left off the Example and Counterexample columns because they're obvious. I'd expect the fixture to fill them in form me. I didn't include a table about the balance being correct because I wouldn't think the programmers would need it, nor would others need it to believe the programmers understand it.

One thing that worries me about this is that the table doesn't rub your nose in combinations. Such a table is more likely to force you to discover business rules you'd forgotten about, that you'd never known about, or that no one ever knew about. (Well, it does that for a while - until the tedium makes your mind glaze over.) In a way, this fixture makes things too easy.

On the other hand, there's something to be said for protecting later readers from the process through which you convinced yourself you understood the problem.

I'm tempted to launch into implementing this, but I have other things to work on first.

## Posted at 11:49 in category /fit [permalink] [top]

Thu, 21 Sep 2006

Do good work

I read Tom Wolfe's The Right Stuff a zillion years ago. One passage hit me then, and it's stuck with me. The time is somewhere in the beginning of the Mercury program:

Asking Gus [Grissom] to "just say a few words" was like handing him a knife and asking him to open a main vein. But hundreds of workers are gathered in the main auditorium of the Convair plant to see Gus and the other six, and they're beaming at them, and the Convair brass say a few words and then the astronauts are supposed to say a few words, and all at once Gus realizes it's his turn to say something, and he is petrified. He opens his mouth and out come the words: "Well... do good work!" It's an ironic remark, implying "... because it's my ass that'll be sitting on your freaking rocket." But the workers start cheering like mad. They started cheering as if they had just heard the most moving and inspiring message of their lives: Do good work! After all, it's little Gus's ass on top of our rocket! They stood there for an eternity and cheered their brains out while Gus gazed blankly on them from the Pope's balcony. Not only that, the workers—the workers, not the management but the workers!—had a flag company make up a huge banner, and they strung it up high in the main work bay, and it said: DO GOOD WORK.

That came to mind when I read this abstract:

This paper presents a fully independent security study of a Diebold AccuVote-TS voting machine, including its hardware and software. We obtained the machine from a private party. Analysis of the machine, in light of real election procedures, shows that it is vulnerable to extremely serious attacks. For example, an attacker who gets physical access to a machine or its removable memory card for as little as one minute could install malicious code; malicious code on a machine could steal votes undetectably, modifying all records, logs, and counters to be consistent with the fraudulent vote count it creates. An attacker could also create malicious code that spreads automatically and silently from machine to machine during normal election activities—a voting-machine virus. We have constructed working demonstrations of these attacks in our lab. Mitigating these threats will require changes to the voting machine's hardware and software and the adoption of more rigorous election procedures.

Since this is by no means the first report, I feel safe in saying Diebold is not DOING GOOD WORK.

I wish people who could matter—that especially means you, Fourth Estate—cared. We're all on top of the freaking rocket. (Not just the US, since the size of our military and economy puts much or all of the world on the rocket too.)

I'm sure there are people at Diebold who feel embarrassed or even humiliated by what their company is selling. If any one of them wants throw caution and good sense to the winds and hang up a DO GOOD WORK banner, I'll buy it for you. Seriously.

## Posted at 20:10 in category /misc [permalink] [top]

Learning from you

I've been invited to the Software Practice Advancement Conference. The idea appeals: expense-paid trip to London, opportunity to rouse the rabble along some lines I'll be previewing here as I have time, and a conference that's said to be good (I've never been). On the other hand, I hate overseas flights because I can't sleep on planes, and Dawn almost certainly can't come with.

Here's what would tip me over the edge. There are lots of people I could learn from in London. If there are teams there who do something really well (making small stories, writing FIT tests, release planning, etc. - anything), I would like to come work with you for several days. Not just visit and watch, but act as much like a team member as I can. Let me know.

P.S. The idea of visiting practice is part of what I want to rouse the rabble to, something that lives in the same space as the MFA for Software, something that's part of my formal discussion of Jim Waldo's OOPSLA essay On System Design, which will be titled something like Surviving in a World of Ever-Looming Malignity: Or, Monasticism for the Married.

UPDATE: Yes, I'm not expecting to be paid for the visits.

## Posted at 19:16 in category /conferences [permalink] [top]

Mon, 11 Sep 2006

Across the chasm

A couple of years at the Agile conference in Calgary, a big topic of discussion was whether Agile was poised to cross the chasm from visionary early adopter types to the early mainstream. This year at Agile2006 it sure seemed to me we had.

If I recall the high-tech adoption curve correctly, a big difference between the Visionary early adopters and the Pragmatist early mainstream is who they talk to. The Visionaries talk to the Technology Enthusiasts to find ways to have big wins. The Pragmatists talk to other Pragmatists, especially ones in the same industry, to find ways to have safe wins.

My main client these days is a good example of a Pragmatist. Before adopting Scrum, they methodically went to visit other companies that had been using Scrum successfully. That's the first time I've seen that.

Agile in the mainstream is definitely a good thing, but every silver lining comes with a cloud. I worry that the clear sunshine of innovation will be obscured by the mists of scale. (Sorry about that...)

If you believe Moore, the mainstream market naturally shakes out into a single dominant "gorilla" and several "chimps" that scrabble for the leavings. He uses Oracle as an example of the gorilla, companies like Sybase as examples of chimps. Or you could think of the relational model in general vs. other ways of organizing and accessing persistent data.

On the one hand, that's good for innovation: the chimps have to find some angle to distinguish themselves from the safer gorilla choice. On the other hand, the innovation is constrained: it can't be too wildly different from the gorilla or else you're no longer in the mainstream market. (The distinction here might be between object databases—never made it in the mainstream—and adding object-ish features to relational databases or just figuring out how to make object-relational mapping work.)

But more important, to me, is a redirection of talent. The gorilla of Agile is Scrum + a selection of XP practices (perhaps most often the more technical ones like continuous integration or TDD). Consultants and consultancies can make more money, grow their practice faster, and have more influence by helping new teams start with Scrum+XP and by taking steps to make Scrum+XP more palatable to large segments of the mainstream market (the later mainstream, what Moore calls Conservatives). People doing that don't have time to do other things.

We saw that at Agile 2006, where the proportion of novices perhaps reached some sort of tipping point that made it more like a conventional conference. That's not a criticism: the Agile Alliance is there to help Agile projects start and Agile teams perform—says so right on the website—and making sure the beginner is served is absolutely necessary to those goals.

So that's all good. But I'm not comfortable unless I've got the feeling that there's something just beyond the horizon poised to surprise me. I'm not usually the one to find it: I'm more of a synthesizer, amplifier, or explainer than an innovator. So I selfishly need people out there searching, not teaching Scrum+XP.

I'm getting a sense that some significant chunk of people are ready for Agile to take a surprising jump forward. See, for example, what Ron Jeffries has recently written. Some part of my next year will be spent in support of that. I have at least one whacky idea, a bit related to the MFA in software.

I'll be poised to spring into action soonish. Just let me get this book done, please let me get it done, without any of the changes in response to reviewer comments introducing a nasty bug.

## Posted at 21:34 in category /agile [permalink] [top]

Tue, 29 Aug 2006

Two conferences

Give a thought to going to the second Continuous Integration and Testing Conference in London on October 6-7. I went to the first one and liked it. I'd go to this one, but I understand you can't take water on planes now and I'm mostly water.

I will be going to the Simple Design and Test conference near Philadelphia (USA), on October 27-29.

And RubyConf is sold out already. Rats. That'll teach me.

## Posted at 09:18 in category /conferences [permalink] [top]

Mon, 28 Aug 2006

Two claims about clean code

Agile depends critically on programmers keeping the code clean. Lots of us know important steps in making code cleaner: remove duplication, rename methods and classes as their purpose changes, be wary of if statements, check if methods are composed, move methods that display feature envy, and the like.

I make two claims.

1. A lot of the craft of being a good programmer is how you sequence those individual steps, how you make them work together.

2. Standards of cleanliness ought to be situational. For example, consider an application in an extremely fluid domain, one where there's a considerable business advantage to having a code base that's ridiculously flexible, one whose capabilities suggest new features. Contrast it to a purely CRUD app. The first ought to be much more aggressive about naming, I bet, and I wouldn't be surprised to see the programmers favoring embedded domain-specific languages. (As someone once said, "All large systems eventually end up with a Lisp implementation inside them.")

I wonder how I could learn more about that? The best way would be to work with other people on several disparate systems for a long time—which is not in the cards.

## Posted at 11:17 in category /agile [permalink] [top]

Sat, 12 Aug 2006

Over the hump

I have finished the review draft of Scripting for Testers. I am going on holiday.

## Posted at 16:29 in category /testing [permalink] [top]

Fri, 04 Aug 2006

Workshop on Agile performance testing - Exeter, England

Posted at the request of Ross Collard, organizer.

WOPR7 is a workshop on agile performance testing. See www.performance-workshop.org for details, including how to apply.

It will be held in Exeter, England on October 12 - 14, 2006 (Thursday - Saturday). WOPR7 is a peer-level mini-conference, invitation-only, deliberately small and collegial, and free. James Bach will conduct a related one-day tutorial on Wednesday, October 11, also free.

Prior WOPR workshops have uniformly been rated outstanding. WOPR6, for example, was held on the Google campus in California last April, and attracted 120 applicants for the 20 seats available.

Some myths may make people ambivalent about applying to attend WOPR7 --

Myth 1.. Travel to the U.K. is a hassle / we do not have a budget for European travel / the food is bad in England. Actually, Exeter is a delightful, semi-medieval university town. The climate will be great in October. So will the camaraderie.

Myth 2.. "In my organization, we do not do agile performance testing and thus do not have any experience reports (ERs) to share on this topic." In response, I ask questions like: "Well, do you test and compare the performance iteratively?", and "Do you have to be agile and respond adroitly to fast changing conditions, often under tight deadlines?" They always say: "Of course! But we do not rigorously follow XP, Scrum, etc."

Myth 3.. "I would like to go to WOPR7 as a participant but have no ER to submit, so I know I will not be selected." We have room for motivated beginners as well as experts.

Myth 4.. "I would like to go to WOPR7 and I do have a story (an ER), but it could not possibly be selected over ones by Harty, Sabourin, Pearl, Barber, etc.". See comment above on myth #3.

## Posted at 07:43 in category /conferences [permalink] [top]

Mon, 31 Jul 2006

The Gordon Pask Award 2007

Each year at the Agile200X Conference, the Agile Alliance presents the Gordon Pask Award for Contributions to Agile Practice. Here's its description:

The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice demonstrate, in the opinion of the Award Committee, their potential to become leaders of the field. The award comes with a check for US$5000.

Last year's recipients were J. B. Rainsberger and Jim Shore. This year's are:

Laurent Bossavit, for translating Extreme Programming Explained into French, for early and helpful activity on the English-language XP mailing list, for organizing a French-language site, mailing list, and wiki, for XP Day France, for the (incipient) thoughts on his blog, and for his championing of code dojos.

The collaborators Steve Freeman and Nat Pryce for helping found XP Day, for their long-time involvement in the Extreme Tuesday Club, for their joint role in the development, evolution, and popularization of the idea of mock objects and its realization in jMock, and for the networks of collaborations they're involved in (storytelling in Fit and scrapheap programming, for example).

(That "network of collaboration" thing presents a problem. Steve and Nat are extreme examples of a problem the Pask award faces: given the collaborative nature of Agile, any boundary you draw that says "this idea, here, is due to that set of people, there" is bound to leave out contributors. Steve and Nat are far from the only people who've worked on mock objects, and they've both collaborated with other people on other things. Where do you draw the award's line? There'd be some justification for giving it to the whole of London, or at least to the whole Extreme Tuesday Club.

(The committee—Rachel Davies, J.B. Rainsberger, Jim Shore, and me—discussed such matters for two and a half hours, maybe more, one night [causing me to rudely skip dinner with Laurent, for what I hope he now thinks is a good reason]. At times, I found myself thinking that maybe the whole idea was too much trouble. Where I ended up is that we should not avoid doing greater good because we cannot distribute all the credit that's deserved. I hope no one gets upset. Believe me, trying to pick two awards from many possibilities is just no fun at all.)

Our criteria are evolving (and, starting with this second year, they're mainly in the hands of the past recipients). We are looking for people who provide both ideas and actions. We want people who are advancing the state of the practice. But we also want people who are spreading knowledge of the existing state of the practice, so that Agile teams know what more there is to learn. And we also want people who are helping people on a personal level, not just at the abstract level of ideas.

## Posted at 09:31 in category /conferences [permalink] [top]

Sun, 30 Jul 2006

An unhappy trend: a looming humanist/technologist split

This trend is one I had trouble explaining at Agile 2006, so bear with me. (Or skip the whole thing - might be the best use of your time.)

Imagine telling the story of how the bicycle evolved. You could tell it as a story of technology. In it, the bicycle evolved from a crude prototype to today's designs because of improvements in materials technology, a greater understanding of applying human power to spinning wheels, and changing "ecological niches" (from unpaved or poor roads to both roads that allow greater speed and also steep paths ridden purely for recreation).

You wouldn't really include people in that story. Yes, tires got wider because people all of a sudden chose to ride down mountains, but once that niche was chosen, the form of the bicycle can be seen as inevitable. Or you might note that the frames of some bicycles are shaped differently because (first) women riders wore skirts and (later) because of tradition. But, allowing for that, the form of the woman's frame follows function.

In such a story, one of technological determinism, it would be absurd to say that a mountain bike would look different if, say, society's class structure were different.

But there's another kind of story, one of social determinism, where human relations play a driving role. A socially deterministic story of ethernet might point out that squirting packets into the ether, checking for collisions, and possibly resquirting isn't an inevitable design. After all, at one point, token ring networks were a pretty serious contender, and they were much more orderly: you wait until you get a token, then you talk. No collisions allowed. A socially determinist story would point out that ethernet was developed at a deliberately freewheeling, relatively unstructured laboratory, not too many miles from one of the most try-it-and-see-what-happens cities in the world (San Francisco). The story would try to work through how the design of ethernet reflected the overlapping societies of the actual humans participating in its creation.

A true socially determinist story sounds weird to me (and, I suspect, you). After all, surely Ethernet was a better design than token ring: no complexity of worrying about a machine crashing while it has the token, for example. And, therefore, someone would have invented it anyway, and it was just happenstance that they worked at Xerox Palo Alto Research Center.

But we technologists tell pretty weird stories, too. Remember "information wants to be free" and "the Net interprets censorship as damage and routes around it"? Those are pure technology determinism, and they seem at least a tad less plausible today than they did around the time of the Netscape IPO.

As something of an instinctive middle-of-the-roader, stories that combine the human/social and the technological make the most sense to me. Agile is noteworthy for telling such stories. For example, the story of an XP project is not the story of a progression of work artifacts (as many processes are); instead, it's a story that includes people sitting in particular physical configurations and deliberately not replicating the ownership relations of the society around them (when it comes to code and expertise).

But at the same time, XP isn't a story you can tell well without talking about technology. It's not a story of a surgical team or a squad of soldiers: it's a story of working software, changed frequently in behavior-preserving and behavior-adding ways.

So, for example, continuous integration is partly about a social reaction to a shifting technological practice. Suppose you're working alone on a machine. You write code that passes the test that motivated it. You also run a whole bunch of other tests that take a few seconds to run. When one of them fails, that's no big deal, so there are no social pressures to be extra careful to avoid them.

In contrast, failing nightly builds disrupt the project much more, so—often—peer pressure is used to prevent them. (In one company, anyone who broke the build had to keep the Frog of Shame on their monitor for all to see.)

Jeffrey Fredrick's article on continuous integration shows how a particular technology—semi-fast notification of semi-substantial test runs—requires a social contract different from both the super-fast local build and the unbearably-slow nightly build:

CI is different [from a nightly build]. Its builds don't need durable build products to be worthwhile. They are a way for a developer to have a conversation with the system, to get reassurance that he has done his part, at least for now. And with a CI build, the cycle time is short, the number of affected parties small, and the cost of failure low. This change in the cost of failure makes for a significant change in behavior—if you'll let it. I've met people who want CI failures to be a shaming event, similar to what happens when the nightly build breaks. But given the nature of a CI build, does this make sense?

[... A] CI build should be tuned to surface failure feedback as quickly as possible, but this feedback is not a management tool; it's an enabling tool. It allows the developer to take responsibility for each check-in in a way that isn't possible (or at least not cost effective) in the absence of such a system. [...] Tracking the failures caused by each individual would only discourage the behavior of frequent check-ins, which you want to promote.

Fredricks' article demonstrates a nice back-and-forth between the technical and social. It's that integrated story that I worry is slipping away. One way it will happen is for those with a technologist bias (most people on our teams) to vote with their feet. The dominant methodology today is "Scrum plus some of XP." The parts of XP that often seem to get left out of the "some" are the human ones: pairing, shared code ownership. Whatever you may think about the merits of XP's particular practices, they do tend to make it obvious that a team has to form some sort of a social contract. Maybe the habit sticks. Maybe it won't when the team choses from a buffet of practices, picking the sweet corn of refactoring over the brussels sprouts of shared code ownership.

Perhaps because I have a technologist bias, I'm more alarmed by social stories that include no technology. These are stories that involve how Placating people interact with Blaming people, or how INTJs interact with ENFPs—but don't involve what they're interacting about. Such models apply as well to a surgical team as to a software team, despite the fact that "crash" has a profoundly different meaning to each of them.

I'm not denying value to pure-technology or pure-social discussions. I just think they're seductively easy. I want more discussions like one that was had in Jeff Grover's and Zhon Johansen's wonderful discovery session at Agile 2006. They began with exercises demonstrating particular human quirks, but the talk afterward seemed to zero in on specific practices.

One exchange sticks out in my memory. There was an exercise about people's personal space. That, in itself, is nothing special (if you already know about it), but I thought the resulting discussion of pairing went in a nice direction. Personal space surely matters in pairing, but someone observed that sitting side by side is different than sitting face-to-face, and that the focus on a shared object (something external to gesture at) allows a smaller personal space. Someone else then noted that personal space is why he so wants chairs with wheels in pairing environments. That way, when people need to have a longer discussion, they can turn toward each other and simultaneously scoot back to maintain comfort. I thought that was cool. It's about social organization of people in a particular physical environment doing a particular task.

Images from the Project for the Scientific and Cultural Aspects of the Bicycle (Amstel Institute), Webopedia.com, The Frog Store, and RoleModel Software.

## Posted at 11:42 in category /agile [permalink] [top]

Wed, 26 Jul 2006

An unhappy trend: leadership

At Agile 2006, I'm seeing or inventing several unhappy trends that I want to call out.

At the first Agile Development Conference (the predecessor conference), I noted with surprise how often the word "trust" came up. At this conference, the surprisingly common word is "leadership." As in: "what's needed to make Agile succeed is executive leadership." Noteworthy: what was once called the Executive Summit is now the Leadership Summit.

As an inveterate champion of the little guy, I've always hated the Great Man theory of business. That's the idea that it all depends on the brilliance and Will of the Jack Welches and Chainsaw Als. I'm seeing that theory accepted as a matter of course in Agile, and it bugs me. It's part of the domestication of Agile: the fitting of something potentially disruptive into the comfortable patterns of life.

Imagine, if you will, the Great Man theory of the Scrum Master: "a team needs the leadership of their Scrum Master to excel." That's the opposite of the truth: the Scrum Master is not a master of the team; she's a master of Scrum: she knows best how the team can use Scrum to succeed. The team leads her, rather than vice versa. As both Mike Cohn and Ken Schwaber have said to me, one of the hardest parts of being a Scrum Master is not leading: is keeping your mouth shut and insisting that the team solve their problem rather than depending on someone else to tell them what to do.

I view executive leadership in the same way. We know how to do software better. It's the executive's job to support us in doing that—to clear obstacles out of the way of our practice—and not to lead us. We already know where to go. We know how to do our job. We need to be assisted, not led.

## Posted at 06:01 in category /agile [permalink] [top]

Thu, 20 Jul 2006

People who want to learn Ruby in Cleveland

Someone from the NOSQAA is being relentless about getting me to do something at their annual Quality Expo in Cleveland, Ohio, USA, in early November. (It happens that I have a client in Cleveland these days.)

That ties in with some thoughts about the long-overdue Scripting for Testers book. (Which is getting close, honest!) I'm not a fan of two- or three-day 60-people-in-a-room training courses. Even if there are lots of exercises, most of the course doesn't stick. It doesn't cause the kind of change that I want to cause.

So, when people call me and tell me they want me to train their testers in Ruby, I'm not planning on offering them such a course. Instead, I'm going to pattern my offering on the way I do consulting, which is to fly in for a week per month, sit down with people at computers and do work on their product, repeating the trips until they decide I'm no longer worth the money.

The Ruby variant would go like this: I won't train the testers in Ruby. I wrote a book that's supposed to allow them to self-train. So I want the company and testers to demonstrate that it won't all be a waste of time by working through parts 1 through 3 of the book on their own and starting to apply Ruby to their own projects. I'll come in, once or more, to help them with those projects, make observations, give impromptu mini-courses on topics I think they should know. That will be more expensive and time-consuming than a stand-up course, but it will have a much higher chance of working.

But I can do more, tying Ruby into my normal consulting. Suppose I'm flying to a city once a month anyway. What I'd like to do is organize something akin to a flash mob: a flash user group of testers (and others) who want to learn scripting. They'd learn it on their own, in concert or individually. When I'm in town, we'd have dinners devoted to the topic. At some point, we'd cap it off with a one-day mini-conference on Ruby and testing. I'm envisioning that the morning would be devoted to enticing beginners. Again, I'd downplay the lecture. What I'd want is the members of the existing flash user group to pair up with newbies and show them the Wonders of Ruby. In the afternoon, we'd have advanced topics. Perhaps something like RubyConf would work: have people present how they've used Ruby in their job. That way people would get ideas, hook up with people doing similar things.

Then, having gotten things going, I would ride off into the sunset.

To see if that works, I'd like to do a dry run in Cleveland. The question is whether there's interest. If you're near Cleveland and interested, drop me a line. Forward this URL to people in Cleveland. Let's see if we can get a critical mass going. If so, I'll tell Ms. Persistent-Far-Beyond-the-Call-of-Duty-They're-Lucky-to-Have-Her that she's won me over.

## Posted at 09:03 in category /ruby [permalink] [top]

Wed, 19 Jul 2006

Agile 2006 Topics

Here are things on my mind these days. If you're at Agile 2006, and you have experience to offer, please let me listen to your story.

• When people start working on business-facing tests, where do they end up? I'd like to hear stories of what you tried, what you persisted in doing, what you slid back from, what you rightfully rejected.

  (Background: I don't have the same knowledge of the steady state of testing as I do of other aspects of the project. For example, if you told me you have standups, but didn't pair, I'd shrug. Not unusual. If you told me your team always programmed in pairs but didn't have standups, I'd be surprised. For business-facing testing, I don't know what to be surprised at and what to shrug at.)

• Part of what happens in some Agile projects is a transition from this style of testing:

  

  to this:

  

  In the first, there's a limited amount of testing, almost exclusively manual, through the same interface the user uses. The transition is to a lot more automated testing of pieces of the system and fewer end-to-end tests (be they automated, manual exploratory, or a combination). This frequently causes concern: how will we be sure the pieces fit together?

  What happened in your project? Did the concern go away? Was it time that did it, or did you find some other way to convince people? What did you do before the concern went away?

• Tell me the story of your product director. How uncomfortable was she at the start? What were her big worries? How comfortable did she get? How did that happen?

Thanks. I should be easy to spot. I still look roughly like the picture at the top of the page, though with a mustache and dorky goatee now. Something like this:

## Posted at 16:05 in category /conferences [permalink] [top]

Tue, 18 Jul 2006

Refactoring, defined

A while back, I sat in while Ralph Johnson gave a dry run of his ECOOP keynote. Part of it was about refactoring: behavior-preserving transformations. The call was for research on behavior-changing transformation that are like refactorings: well-understood, carefully applied, controlled.

Ralph mentioned that persistent question: what does "behavior-preserving" mean? A refactoring will change memory consumption, probably have a detectable effect on speed, etc.

My reaction to that, as usual, was that a refactoring preserves behavior you care about. Then I thought, well, you should have a test for behavior you care about. ("If it's not tested, it doesn't work.") That, then, is my new definition of refactoring:

A refactoring is a test-preserving transformation.

If you care about performance, a refactoring shouldn't make your performance tests fail.

## Posted at 21:30 in category /coding [permalink] [top]

Tue, 11 Jul 2006

National debt

I stumbled across a bunch of graphs about the US national debt, courtesy Mark Wieczorek. Keeping in mind my suspicion of simplistic use of numbers, one graph is still pretty interesting for someone who grew up, as I did, hearing all about "tax and spend" liberals of the Lyndon Johnson variety. It's below, showing the yearly increase in the debt in constant dollars. I've overlaid color. Republican Presidential administrations are red, Democratic blue. The bars across the top show control or near-control of Congress.

Note: the vertical lines are approximate. If I were truly serious, I'd make some sort of effort to determine if the lines should be shifted to the right (since Presidents don't have an instantaneous effect). However, I'm mainly doing this because I'm stuck on something I'm supposed to be writing, I need a break, and I'm in a hotel room in Cleveland.

The current situation is worse than that graph makes it appear, as the high level of yearly debt under Bush is projected to continue, as shown on the right (non-constant dollars).

The final picture is my family. The small ones get to pay it off—the "bridge to nowhere", an overpriced prescription drug plan, Paris Hilton's tax break on unearned income, sloppy accounting in Iraq, a culture of corruption that's far beyond what Democrats achieved in their days of power, all of it. That's shameful. I expect my children's generation will look at the adults of today and call us lazy, feckless, self-centered, and stupid. With justice.

## Posted at 20:03 in category /misc [permalink] [top]

Sat, 08 Jul 2006

The bloat trochar and the rulebook

Jeffrey Fredrick and Kevin Lawrence liked this, so I'm posting it here.

Background: On the Agile Testing list, someone wrote:

To perform surgery, you always first scrub.

Always always always. One size fits all. No exceptions. Hire a nurse whose only job is to make sure everyone does it.

Someone replied:

This statement ignores context, and its application breeds contempt not only for context but for nurses.

I was in one of those moods, so I wrote this:

I've been talking about scrubbing for surgery with my wife (who both does it, and has a grant proposal out to study something related to it). What strikes me about it is something that's been said here before about testing in Agile projects, but I think needs to be said again.

One thing about scrubbing is there is universal agreement about the goal: minimize the amount of "trash" (bacteria, etc.) that gets into the wound.

Even though, in a non-emergency, you do always always always scrub, I was surprised at how much variation there is. Some people have a rule that you scrub each of four sides of each finger ten times. Some people think you don't have to count; you just have to scrub for ten minutes. Some scrub for five. People scrub with different things. And so on.

Although the rules vary, they are rules, rather than judgment calls. People do not scrub according to today's context. They scrub the way they always scrub, which is likely the way they were taught or the way their colleagues do it. It's not really possible for them to judge context -- there's just too much noise in the causal chain from scrubbing to surgical outcome. That also makes experimental justification of scrubbing techniques hard. Still, if pressed, a surgeon could make an argument for her style in terms of the agreed-on goal.

The other thing that struck me is the degree to which the (rich) world has been constructed around the goal of sterility.

• Being as sterile as surgeons ought to be is unnatural. Therefore, there are mechanisms in place to make it harder to give into nature. The role of scrub nurse is one such mechanism.

  Obsessive drilling in the rules is another. Because surgeons have to push in the opposite direction from what's Only Natural, strict rules are safer on average. In the way that most people think they're better-than-average drivers, most people think they're better-than-average judges of context. If they err, they'll err on the side of doing what's Natural. So you must push the pendulum a little further in the other direction, or you reduce the number of times they feel the need to make a judgment rather than follow the rule.

• The trappings of the world are built assuming you will not be able to scrub sometimes. Field dressings don't have to be sterilized; they come that way. Ditto for instruments. Ranchers and veterinarians carry bloat trochars. If they come upon a cow with life-threatening bloat, they don't have to