What does your workspace say about you?

December 10, 2007
URL:http://www.drdobbs.com/architecture-and-design/is-your-workspace-informative/204800604

A careful observer of the current software scene might have recorded these recent examples of peculiar behavior in development teams:

1. 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.
2. 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.
3. 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."

[Click image to view at full size]

Bjarne Stroustrup's workspace.

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.

Workflow and Lavaflow

The lava lamp project described here is a respected example of an eXtreme Feedback Device. So respected, in fact, that it has achieved something of cult status. The motivation behind building such devices is, as Agitar Software founder Alberto Savoia describes it, "to get your team to pay attention to the project/software status and metrics that you care about."

Extreme feedback doesn't necessarily mean a lot of feedback, Savoia points out. In fact, devices like the lava lamps deliver a very small amount of information, as little as one bit, but it is highly important information ("the metrics that you care about") and it is delivered continuously and automatically.

Other teams have used different devices for the same purpose, including actual traffic lights, Ambient Orbs, LED cubes, a water feature (keep the waterfall flowing, the bucket spilling, etc., to keep the build succeeding), sound effects like sirens, retro LED displays, and in one case, a trailer hitch that caused a plaster deer to flop over onto its back, throw its legs in the air, and wave a flag reading "Help!! The build is broken!!!"

The extremely eXtreme Feedback Device proposed by one programmer—a hack that would use subversion to identify the programmer(s) responsible for the latest break in the build, orient the team's USB missile-launcher accordingly, and bounce a (foam) missile off the guilty head—has not yet been successfully implemented.

The team that was spending all that time updating colored index cards was maintaining an Information Radiator.

Information Radiators carry more bits than eXtreme Feedback Devices, and serve different purposes. There is a lot of variety in how teams implement Information Radiators, but all are big visible charts that depict important measures of the current state of the project. One device any team might use is a whiteboard for brainstorming. This brainstorming might take the form of developing stories (roughly equivalent to features), and that can lead to setting up a board with cards (to represent these stories) that can be moved across the board as progress is made. Perhaps a row of cards represents a week's work.

One team used green cards to denote features for end users, blue cards for features for staff use, orange and red flags for varying degrees of incompleteness, yellow tags for milestones, and red post-it notes for particular types of questions. Another team may use colored squares on a whiteboard to represent the status of tests: red for failed, green for passed, and Xs for tests not yet run. Then there are burn charts. These charts simply plot the degree of project or task completion against time, although getting into the subtleties of how that plotting is done is very much what IW is about. As Alistair Cockburn points out, choosing the right milestones is critical and can mean that you get bad news early—when you can do something about it. Also, opinions differ on whether it's better to use a burn-down chart, which slopes down to a goal of zero steps to go, or a burn-up chart, which rises toward a goal of 100 percent completion.

And the programmers building dollhouses? They were participating in a workshop to consider what features were good and bad in the layout of workspaces. Because beyond the eXtreme Feedback Devices and Information Radiators, the notion of Informative Workspaces also encompasses the physical layout of the team's workspace, including shapes and orientation of desks/tables (no annoying knee-well, desks oriented to facilitate pair programming if that's part of your methodology), communal space, and a general layout that causes everyone to need to walk through the team workspace to get to any private, individual spaces—to ensure interaction. (Here's where it really starts to sound a little like feng shui.)

One thing that the participants in the workshop learned was that there is much to learn about implementing Informative Workspaces in the best way for your programming team. Some of these eXtreme Feedback Devices and Information Radiators are better than others, or at least better for your team, as should be clear from a moment's consideration of how morale and concentration would be affected if, at unpredictable intervals, a siren went off in your team's workspace.

Artifacts of Agility

I've consciously skated past the task of placing Informative Workspaces in its proper place in the conceptual and historical hierarchies of software design methodologies, but I should at least acknowledge that Informative Workplaces is a concept developed in the context of the Agile design methodology. It presupposes many of the aspects that characterize Agile development, including the emphasis on pair programming and a high degree of interaction among team members and test-driven development. If you're not doing Agile development, you may have to translate some of the terminology and even some of the ideas in Informative Workspaces, but you should still find a lot in it of use. And it seems to me that, despite the protestations of the purists, many development teams pick and choose elements of these carefully constructed methodologies and throw out other elements and end up with their own team-specific or project-specific methodology. And if it works for them, why not?

So what's the experience of working in an Informative Workspace? You may have noticed a recurring theme in some of the Informative Workspace details described here: a sense of fun, of whimsy. Those lava lamps, for example. It turns out that the pair of lava lamps is an excellent feedback device, because it provides a clear and unambiguous signal without being obnoxious. And they're sort of whimsical, which also turns out to be a highly desirable feature of a work environment, at least according to a lot of the people who have implemented Informative Workspaces.

So does it get the job done? What's the verdict on Informative Workspaces and productivity?

At first, it seems odd that for a discipline that emphasizes testing so much, there is little more than anecdotal evidence for the discipline's success. But in fact, it's hard to imagine how you would construct a scientific study to compare two different software methodologies. Could you actually assign programmers randomly to experimental groups, give each group a methodology to use and a months-long project to tackle, and observe their results? Sounds a little impractical, but anything short of that will run afoul of self-selection bias or other experimental design problems, it seems. And then there's the problem of defining success. One goal of Informative Workspaces is programmer satisfaction. That, at least, is not only measurable, but Darwinian: If IW makes programmers significantly happier and programmers have any say in the methodologies they use on software development projects, IW will grow.

And there is evidence that Informative Workspaces make programmers happy. A Canadian researcher (Elizabeth Whitworth, "Agile Experience: Communication and Collaboration in Agile Software Development Teams," Carleton University) talked to a sizeable sample of Agile and nonAgile developers and found that Informative Workspaces as an element of Agile development "was seen as truly motivating, [with] team members... more likely to exhibit a strong sense of pride, purpose, and excitement in work."

And that can't be bad.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.