I thought you said NOT to cross the streams!

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.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Continuous Integration, Pair Programming. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Mark Johnson

    Yeah, subversion lends itself very well to continuous integration. Once you get used to diffing and merging, it gives you real sense of security and devil-may-attitude about making changes to any file you want. You never second guess yourself and you are never slowed down by pessimistic lock scenarios.

    Obviously dealing with binary source files (Flash, PSD, AI etc.) still require locks.

  • http://dotnetjunkies.com/weblog/johnwood John Wood

    I can’t argue with that… although I would like to add that I think it’s worth the cost. And no I don’t work for them :)

  • Jeremy D. Miller

    Yeah, but Subversion is a lot cheaper than Perforce;)

  • http://dotnetjunkies.com/weblog/johnwood John Wood

    Perforce is quite good for that… it tells you that the file is already checked out, but allows you to check it out anyway and will then merge in the changes (either automatically or interactively). I think the trick is to make sure your source files are sufficiently granular to avoid the locking issues in the first place.

  • Jeremy D. Miller

    John, I’m in the school of thought that says that pessimistic locking in source control is nothing but friction. Subversion handles the merging quite well anyway. I really don’t think it’s fully possible to use pessimistic locking and do continuous integration. I’ve been forced to try it before with Visual Unsafe, and it wasn’t pleasant.

    Just a little communication can make the merge problems go away.

  • http://dotnetjunkies.com/weblog/johnwood John Wood

    Hmm.. why not just use source control? Most SCSs let you check out files which locks them from changes by others.