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

Sat, 04 Sep 2004

Cybernetics, agile projects, and active adaptation

I just read the first chapter of Andrew Pickering's forthcoming The Cybernetic Brain in Britain, a history of - and reflection on - the British cyberneticians from the 50's on.

As Pickering tells it, these people were concerned with the brain, but not as an organization of knowledge, a sack of jelly in which representations of the world are stored and processed.

What else could a brain be, other than our organ of representation? ... As Ashby put it in 1948, 'To some, the critical test of whether a machine is or is not a "brain" would be whether it can or cannot "think". But 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' (1948, 379). The cyberneticians, then, conceived of the brain as an immediately embodied organ, intrinsically tied into bodily performances. And beyond that, they conceptualised the brain's special role to be that of an organ of adaptation. The brain is what helps us to get along in, and come to terms with, and survive in, situations and environments we have never encountered before... the cybernetic brain was not representational but performative, as I shall say, and its role in performance was adaptation.

This gives me a couple of thoughts. First, we can think of the agile bullpen, containing people, furniture, and source code, as an embodied organ of adaptation. The team is something that gets information and does something about it (change the code). The better the team, the more flexibly adaptable it will be, and the better it will survive in the business world.

(I'm picking the bullpen as the unit of adaptation because I want to talk myself out of the notion that everything that matters is in the heads of the team members - some of it is "in" the configuration of the room, the Big Visible Charts, the source code, the Lava Lamps, the rituals that people take part in and the rules they follow and reinterpret. Also, I'm making a bit of reference to Searle's Chinese Room critique of AI, though I'm not sure to what end.)

The second thought ties in with this quote:

Norbert Wiener's basic model for the adaptive brain, the servomechanism, is, in one sense, a passive device. A thermostat simply reacts to unpredictable fluctuations that impinge upon it from its environment. If the temperature in the room happens to go up, the thermostat turns down the heating, and vice versa. In contrast, the distinctive feature of Walter and Ashby's models is that they were active. They interrogated their environments and adapted to what they found. Walter's tortoises literally wandered through space, searching for sources of light. Ashby's homeostats stimulated their environments with electrical currents and received electrical feedback in return. Such cybernetic devices, one could say, enjoyed a relationship with their environment which was both performative - the devices acted in their world, and the world acted back - and experimental: they explored spaces of possibility via these loops of action and reaction.

Agile projects are not as passive as a thermostat. They stimulate the world by releasing software, causing the world-of-the-business to stimulate the project back. But there seems to be an emerging critique of the current stage in Agile that accuses it of being too passive. Tim Lister's keynote at Agile Development Conference charged the listeners to do more than passively accept requirements from users: instead we should exhibit (and develop) expertise in what users need. The new Agile-Usability list kicked off with some blasts at what can happen when a business expert who doesn't understand usability creates a UI feature by feature and the programmers passively do what she wants. Mary Poppendieck's keynote at XP/Agile Universe talked of the need to deliver a whole product to the business, and others appalled by how often successful-in-their-own-terms Agile projects get taken down by organizational struggles and interests are trying to figure out how to convert receiving organizations into something Agile enough to really use their Adaptive Bullpens well.

In so-far-sketchy conversations with Pickering, we've both been struck by similarities between Agility (as I describe it) and the cyberneticians (as he describes them). Perhaps we of today can learn from the cyberneticians of yesteryear - not least, how to avoid their fate: because that polyglot, promiscuous field has pretty much vanished, except from fond memories. The anti-discipline that produced von Foerster's "Act always so as to increase the number of choices" is itself no longer a choice.

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

Helping Norm Kerth

Norm Kerth is the author of Project Retrospectives, an early proponent of patterns, and a nice guy. He suffered a disabling brain injury in a car accident and can't work for sustained periods.

Karl Wiegers has bunches of shareware process aids (mostly Word and Excel templates for various things). Net proceeds will go to the Norm Kerth Benefit Fund.

A worthy cause. And you ought to buy Norm's book, too. It's a good and useful read, in the Weinberg style.

## Posted at 12:22 in category /misc [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