A careful observer of the current software scene might have recorded these recent examples of peculiar behavior in development teams:
- A programmer takes away time from development work on an important company software project to design a circuit that can drive lava lamps. Tapping into the parallel port of the team's CruiseControl server—a task that, in the past-DOS, dot-net world, involves finding the right DLL, accessing the right class, and modifying one of its methods—he rigs up a device to power either a red lava lamp when tests fail during a build or a green lamp when all tests pass—that is, a successful build. Later, he adds a disco ball that turns on whenever there is a build in progress. The team applauds his achievement.
- A development team spends hours every week moving index cards on a wall covered by a grid of boxes. Each box contains variously colored cards pinned by strategically colored thumbtacks. Strings run from a thumbtack in one box to a different-colored thumbtack in another. The team members earnestly update the cards and move them around according to a rigid schedule. And this is not a discipline imposed on them by some bean-counter manager, but something they took on willingly.
- At a developer conference, programmers spend hours building dollhouses with little LEGO people and placing them on windowsills and under desks. They speak earnestly of "keeping the furniture police at bay."
Another Brit on The Wall
What's on display in all these cases of peculiar programmer behavior is one or another aspect of "Informative Workspaces", the feng shui of software-development methodology.
You're right, that was glib. The only connection between Informative Workspaces and the Chinese practice of feng shui is that both are concerned with the effect of a workspace on those working in it.
But Informative Workspaces are really about building effective feedback mechanisms to support programming teams. Rachel Davies—who owns the informativeworkspaces.org domain, so she should know—and David Hussman explained at a recent OOPSLA that these feedback mechanisms typically fall into one of two general categories: (1) manually updated nonelectronic visual displays, and (2) electronic devices hooked up to automated processes.
The former, in the familiar Capitalize Important Concepts style of Design Patterns, are called "Information Radiators," and the latter are called "eXtreme Feedback Devices." In a newsletter of the British Computer Society, Ian Alexander and Kathleen Maitland referred to this terminology as "hideous neoBlairite jargon" and suggested replacing the term "Information Radiator" with the briefer term "The Wall." Which I think could justly be called "neoPinkFloydite."
But the terms really are meaningful. The "Information" or "Informative" part, for example, means that the walls should talk. As Kent Beck puts it, when an interested observer walks into your team space, s/he should be able to get a general idea how your project is going in 15 seconds, and be able to get a deeper perspective on real or potential problems by looking more closely. Informative Workspaces.
