Projector Programming

We have recently been doing programming with more than pairs using a projector rather than all crowding around a screen. So far we are in the early stages of the development cycle where we are collecting UserStories and ReleasePlanning.

We have found more ideas surfacing since everyone can clearly see what is going on.

The mechanics are

conference room that seat about 15-20
main laptop
network connection
projector
large and small screens
one or two other laptops
numerous white boards, flips charts, and large post-it notes (4x6 variety)

The main thread of development/investigation/discussion occurs using the main laptop which is projected onto the screen. Ideas flow freely in the group as the keyboard owner, the person sitting in front of the laptop, directs the conversation and records the ideas into the presentation, modeling tool, and code snippets.

The other materials in the room, e.g. laptops, whiteboards, flip charts, and post-it notes are used for spike discussions and implementations. -- RickyWest

We're starting CodeReviews here, and at the last one I got sick of writing down notes on the printout. Next time, we've arranged for a laptop and a projector, and we'll fix the problems in the code we're reviewing on the spot. -- RobertWatkins

In our early days, we tried just to put "markers" in the code to remember what needed to be changed when the "responsible" developer came back to work on the updates from the review. It turned out that when the engineer came back to look at the problem; he had forgotten what the issue was. We thought we would save time by just marking the location; but we wasted time trying to recover the discussion at the "meeting". Eventually, we just changed the code in real-time to reflect the needed changes. If the changes were too involved to do in real-time, then comments were planted in the code to record the issue in as much detail as was thought appropriate by the team--sort of an index card in the code.

These days, I would probably recommend using a real index card to record the bigger issue and treat is as a new task to be incorporated in the next/current iteration. Simple changes should just be made in the code. -- RickyWest

We've been using ProjectorProgramming for nearly a year. We also use a conference room, similar to RickyWest. I prefer ProjectorProgramming to the 'traditional' pairing technique where two people sit at the same monitor. For one, I don't feel crowded/confined - while the other person drives I can stand up, walk around, and wave my arms at the screen (ItalianProgramming??). Also, I eat a lot of garlic and if I run out of Altoids, well, you don't want to know what that's like. Anyway, the person not projecting can do quick checks into other areas in the code, or examine documentation while the driver is writing the actual code. -- RonWelte

This might be improved by getting a wireless keyboard and mouse for the main laptop -- then, you just pass the keyboard and mouse around the room.

We do this even for internal business planning - bring up a spreadsheet and heads of each department fill in formulas and assumptions (verbally - one person controls the laptop connected to the projector and types in and drags across the row when everyone agrees usually there are a couple challenges or requests for clarification - and one person moderates in front of the screen with a laser pointer). Like an interactive movie or large video game much more fun than "regular" meetings plus can email everyone a copy right away. In addition we can switch it to cable tv so on occasion will take a break for tennis, world cup etc. Have automatic blinds and lights so very 007 everyone looks forward to these meetings (can't do it all the time but when it is important to get wide consensus we do). Projector(AnyBusinessActivity?) could probably work. Especially SixThinkingHats instead of having paper all over the wall.