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

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.

The photo of Despair is copyright by Carl Robert Blesius and was retrieved from http://blesius.org/gallery/photo?photo_id=1061. It is distributed under the Creative Commons Attribution-NonCommercial-ShareAlike 1.0 license.

The monastery is used by permission of historylink101.net and was found at the Greek Picture Gallery.

The fish picture is copyright by Toni Lucatorto and was retrieved from http://flickr.com/photos/toniluca/61782380/. It is distributed under the Creative Commons Atribution-NonCommercial 2.0 license.

The picture of the dinosaurs is used by permission of clipart.com.

The other photographs did not have copyright notices.

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

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.

 

Syndication

 

Agile Testing Directions
Introduction
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects
Postscript

Permalink to this list

 

Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list

 

Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI

 

Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."

 

Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich

 

Where to Find Me


Software Practice Advancement

 

Archives
All of 2006
All of 2005
All of 2004
All of 2003

 

Join!

Agile Alliance Logo