Dr. Dobb's Journal - January 2008 - (Page 15) d01lead_p4db 11/9/07 12:16 PM Page 15 Send a photo of your workspace to ddj.photos@gmail.com. Informative? Bjarne Stroustrup’s workspace 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 postit 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 burndown 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 January 2008 l www.ddj.com l Dr. Dobb’s Journal 15 http://www.ddj.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.