In my Agile2005 co-keynote, I talked about why I think Agileis akin to cybernetics, at least the British cybernetics of thelate 40's and on. They share an emphasis on these things:

Performance over representation

Rosh Ashby wrote in 1948 that "...to the biologist the brain is not a thinking machine, it is an acting machine; it gets information and then it does something about it." What we usually think of as thinking - building a model in the brain of the world outside it - is secondary; a tool that can be used when useful, ignored when not.

Similarly, an Agile team doesn't depend on a requirements document - a model of a solution - for success. The team is gets a demand for more features and does something about it: it uses whatever tools and internal resources generate the features and keep the paychecks flowing. A good model of the end product turns out not to be such an important tool.

Adaptation

In an as-yet-unpublished manuscript, Andrew Pickering writes that, to these cyberneticians, "... the brain's special role [is] to be an organ of adaptation. The brain is what helps us to get along in situations and environments we have never encountered before."

Similarly, the Agile team's job is to produce a steady stream of working software. Whenever the environment changes and upsets that steadiness, the team adapts until it reaches equilibrium (steady productivity or consistent growth in productivity).

Surprise

The cyberneticians were fond of building complex things, working with them, and opportunistically taking advantage of their unplanned capabilities. I gave the example of Gordon Pask's ear: a device that was trained like a neural net. It took in electrical inputs, sent out electrical outputs, and the outside world's judgments on the outputs trained it to get better and better at producing favored outputs. One way it differed from neural nets is that it didn't start with artificial neurons and connections. It grew them from an undifferentiated soup.

This device had one sense designed in: the ability to detect electrical inputs. In what seems to me a later bout of whimsy, the experimenters attached a microphone to it. By vibrating the whole assembly, the experimenters provoked it to grow a sense of hearing - a wholely unplanned and unexpected sense good enough for it to distinguish 50 cycle from 100 cycle sounds.

In agile programming, it's considered unsurprising if the coding takes you in an unexpected direction and even causes the team to develop new concepts. (See Ward Cunningham's story of Advancers.)

And then I said that's not what I wanted to talk about.

What I wanted to talk about is the fact that cybernetics fizzled. If we share its approaches, might we also share its fatal flaws?

More tomorrow.

One day before the start of Agile2005, the Agile Alliance board voted to create the Gordon Pask Award for Contributions to Agile Practice. Here's its description:

The Gordon Pask Award recognizes 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 and some physical object inscribed with the recipient's name. We expect two recipients per year.

The idea behind the award is that we in the Agile community need to do more to promote and encourage the rising stars of tomorrow. These are people who help other people: both indirectly, by producing tools or ideas other people use, and also through direct support of some Agile community. Rather than planning out the award, thinking through all the gotchas of deciding on recipients, and giving the first award in 2006, we decided to give the Award at the conference's closing banquest just five days later, trusting our membership to be tolerant of mistakes so long as they lead to improvement next year.

The two recipients this year are:

J. B. Rainsberger, for spending a great deal of time helping people on the testdrivendevelopment mailing list, for writing JUnit Recipes, for XP Day Toronto, and for being this year's Agile2005 tutorial chair.

Jim Shore, for his performance as a paper shepherd; for a fine experience report he gave at ADC2003 that, together with his blog, suggest a cast of thought that deserves cultivation; for his work on the Fit specification and the C# version of Fit; and for being a person who holds the Fit world together by doing the sort of organizational and cleanup tasks that are usually thankless.

The selection committee was Rachel Davies, Big Dave Thomas (a different person than Pragmatic Dave Thomas and Wendy's Dave Thomas), and me. We'll be evolving our notion of the prototypical recipient over the years. Putting nominations from the conference members into affinity clusters got us well started on that. But it was remarkably hard to narrow down to a cluster of two: there were six or seven obvious choices.

(Next year, we'll be taking nominations from the entire Agile Alliance membership. And we'll start much sooner.)

I'm really happy we did this.

Oh - you wonder who Gordon Pask is? As constant readers know, I harp on the similarities between the attitudes and approaches that characterize Agile and those of the British cyberneticians of the last century. Of those people, Gordon Pask is perhaps the closest to us. Also, we needed a logo, some cybernetic device seemed appropriate (given how the idea tied into my keynote), and Pask's ear was the only one I had to hand. (It's the picture above.)

• Survive giving a joint keynote with someone far more charismatic.

• Sit down with people to work further on my design-driven test-driven design example. (I've been too busy.)

• For the benefit of people considering business-facing test-driven design, find collaborators to discuss these questions:

  1. In what situations is it a bad idea?

  2. What groundwork needs to be laid? (For example, do you need to have programmer testing well ingrained before making the leap? Or can product-level TDD work before unit-level TDD?)

  3. Anyone doing something they haven't before will hit snags surprising to them but predictable by others. For example, a beginning weightlifter might not expect progress to come in spurts separated by distressingly long plateaus. They'd be more likely to succeed if warned. What snags should new "examplers" be warned about?

  Write up the results.

• Talk to Eric Evans, Rick Mugridge, and others about the intersection between tests and ubiquitous language.

• I sometimes think our rhetoric is too behaviorist: stimulus comes from outside the project, the project responds appropriately and also reconfigures its "circuitry" to be better at responding to such stimuli. As my foreword to the Fit book hints, I'm hung up on the notion that surprise can be internally generated - that ideas from within the project can shape the systems that "drive" it. (See Ward's story of Advancers for an example.)

  If that's (a) possible and (b) desirable, we've woefully understudied the internal conditions that bring it about. There's got to be more to it than refactoring, removing duplication, etc. I'd like to provoke some conversations about what else there is. As Pasteur would have said had he been terser, "Chance favors the prepared mind." Prepared how? (Being attracted to Hutchin's notion of distributed cognition, I'm more interested in the preparation of the team, environment, and flow of events than in preparation of the individual.)

Mugridge and Cunningham's Fit for Developing Software isout now. If you're using or evaluating Fit, you ought to buyit. Youcan find my reasons here(pdf). There are sample chapters here.

Roy Osherove has apost about breakingcode to check test coverage. That reminded me of a trick I'veused to counter a common fear: that changingsomething here will break something way over there.

I started to proudly write up that trick. But the process of putting wordsdown on pixels makes me think I was all wrong and that it's a badidea. Read on to see how someone who's supposed to know what he'stalking about goes astray. (Or maybe it's a good idea after all.)

The picture is of a standard layered architecture. The green star atthe top level is a desired user-visible change. Let's say that supportfor that change requires a change at the lower level - updating thatcloud down at the bottom. But other code depends on that cloud. If thecloud changes, that other code might break.

The thing I sometimes do is deliberately break the cloud, then run the tests for the topmost layer. Some of those tests will fail (as shown by the upper red polygon). That tells me which user-visible behaviors depend on the cloud. Now that I know what the cloud affects, I can think more effectively about how to change it. (This all assumes that the topmost tests are comprehensive enough.)

I could run the tests at lower layers. For example, tests at thelevel of the lower red polygon enumerate for me how the lowest layer'sinterface depends on the cloud. But to be confident that I won'tbreak something far away from the cloud, I have to know how upperlayers depend on the lowest layer's to-be-changed behaviors. I'mhoping that running the upper layer tests is the easiest way to knowthat.

But does this all stem from a sick need to get it right the first time? After all, I could just change the cloud to make the green star work, run all tests, then let any test failures tell me how to adjust the change. What I'm afraid of is that I'll have a lot of work to do and I won't be able to check in for ages because of all the failing tests.

Why not just back the code out and start again, armed with knowledge from the real change rather than inference from a pretend one? Is that so bad?

Maybe it's not so bad. Maybe it's an active good. It rubs my nose in the fact that the system is too hard to change. Maybe the tests take too long to run. Maybe there aren't enough lower-level tests. Maybe the system's structure obscures dependencies. Maybe I should fix the problems instead of inventing ways to step gingerly around them.

I often tell clients something I got from The Machine that Changed the World: the Story of Lean Production. It's that a big original motivation behind Just In Time manufacturing was not to eliminate the undeniable cost of keeping stock on hand: it was to make the process fragile. If one step in the line is mismatched to another step, you either keep stock on hand to buffer the problem or you fix the problem. Before JIT, keeping stock was the easiest reaction. After JIT, you have no choice but to fix the underlying problem.

So, by analogy, you should code like you know in your heart you should be able to. Those places you fall through the floor and plummet to your death are the places to improve. I guess not by you, in that case. By your heirs.

Dave Astels and I will be hosting a workshop at Agile 2005 titled Test-drivenDevelopment and Beyond.

Test Driven Development is becoming a mainstream practice. However, itis a step along the way, not a final destination. This workshop willexplore what the next steps and side paths are, such as BehaviorDriven Development, Example Driven Development, Story-Test DrivenDevelopment.

The idea is that we'll spend up to an hour having participants givebrief pitches for what they think "lies beyond," then split intofocus groups to discuss particular topics. The deliverable is a shortpaper outlining the various approaches discussed, together with peopleinvolved in each.

You need not submit a position paper to attend. If you'd like to present your idea (briefly! which rules out fumbling with a projector), send us your topic. Thanks.

I'll be leading two half-day hands-on sessions at the Amplifying YourEffectiveness conference (November 6-9, Phoenix Arizona,USA). The titles of my sessions bear witness to my belief that I'm noexpert in my topics---but I do expect that collectively we can get somewhere good.

A month ago, I made a consulting trip. I recommended that the clientdo the usual Agile thing: have shippable code with new features everyfew weeks, break each of those releases into stories with user-visibleresults, make the stories more granular than seems possible, make taskswithin a story short with sharp end-points, etc.

Yesterday, I asked how it was going. I got this in reply (reprintedwith permission):

I was actually really fortunate. Shortly after you were here, my wife's pregnancy came to full term. As such, I had to think of life in terms of 2-3 hour slices in case she called to tell me she was in labor. That made it much easier to have the discipline to break a project into smaller chunks.

So here's my new Agile training regimen:

• The team must be composed of people who plan on having a child soon.

• All pregnancies must commence roughly seven months before the project is to start. Remember: on Agile teams, it's not someone's job, it's everyone's job.

• I do not require the use of drugs to keep the mother-to-be on the edge of labor until I judge that she or her partner (whichever is the programmer) really gets the idea of short tasks. As a liberal, I don't believe family life should be subordinated to the needs of the corporation.

It's odd, with innovative ideas like this, that I don't get more business.