We had a little snafu at work today from a lack of communication. It didn't end up costing us any significant amount of time, but it could have. We had two pairs (all the developers in the office) working on different tasks in essentially the same area of the code base. My pair was adding functionality to a new class. The other pair decided that the role of the same class should be different and moved it to a completely different project. We got out of it pretty quickly by splitting the class into two, but that would have been a nasty merge if we hadn't caught it quickly. Just like in Ghostbusters, crossing the streams of coding activity is a way to get a priority user story done fast, but it comes with some risk.
We knew they were working in code very close to us and we should have told them we were working with that class, and they most definitely should have said something to us before they moved the class to the other project. My resolution for tomorrow morning is to make sure we all know what the separate pairs are doing until we can get the coding streams isolated from each other.
I think the danger of pairs stepping all over each other goes down quite a bit as a code base matures. Early on in a project the roles of classes and the project structure can vary wildly. I certainly try to keep parallel coding streams separated as much as possible early in a project. Of course you often don't have much of a choice, so you've just got to be talking much more often and when in doubt, broadcast any breaking changes to the rest of the room. My preferred coding style is definitely heads down, but in the early stages of a project you just can't afford that attitude. I think it's awfully important to get the team in front of a whiteboard several times a day until the technical direction emerges and stabilizes.
Here's another lesson that we relearned today, but in a positive way. Take Continuous Integration to heart. It's more than just configuring CruiseControl.Net, it's an attitude. We got away with working in the same area of the code today precisely because we were checking new code in at least every hour. We were able to reign in the areas where we were diverging rapidly because we were getting constant feedback on our code from the automated builds. Try to break the work into smaller chunks so you can check in code frequently. Frequent, granular check-in's and updates keep the burden of merging to a minimum. Collective code ownership means paying attention to what the other developers are doing too. Put another way, big check-in's usually hurt -- and big check-in's at 4:45 in the afternoon are hazardous to your health. Another reason to keep your automated build as lean and fast as possible is to enable frequent check-in's.
Stale code gets moldy fast. One of the worst mini-blunders in my career was not intervening or rotating someone else into a pair that was struggling with a complex WinForms navigation task. They kept the code out for four days while the main codeline was changing rapidly around them. When the rest of us finally did get involved we compounded the mistake by not throwing the code away and starting over. It took two more days to get the code changes merged in, and another day to refactor that code to where we wanted to go in the first place. All that effort for a story that had been originally estimated at only a half-day to begin with.
Agile processes make a very conscious decision to maximize the communication between team members as a means of eliminating much of the paperwork typical of formal processes. For this very reason, Agile teams typically work in open team rooms. I just can't imagine going back to all of us working in isolated cubicles. I know Joel Spolsky thinks developers do best when they're working in quiet isolated offices, but I think that's a matter of localized optimization. This is a reminder to self -- It might optimize the individual coding productivity over the short term, but it'll probably hurt in the long run with nasty integration problems and an alarming degree of code duplication.