Last week we (BillGuard) finally got out of beta, launching our paid version. As pretty much every software project known to man kind, we had some pressure with this project too. During an extremely short period of time I felt, for the first time, the real meaning of the message behind The Mythical Man-Month.
For those of you who don’t know, the Mythical Man-Month is a book that talks about software projects managements and how our estimations are usually not really what we think they are. The one-line example that gets the point across clearly is “9 women can’t deliver a baby in 1 month”.
When we noticed that our project was going to be a bit late we were extremely tempted to have all developers join in on the effort to get it out the door sooner than later. While we originally had 2-3 developers working on the project full-time (with almost always a couple doing pair-programming), for 2 days we cranked it up so that all 7 of us were working on it.
I can hear you going “What? Just 2 days? Is that his Man-Month?!” Well, let me tell you how odd it was. I wasn’t too thrilled about having so many people working on the same thing, but was prepared to give it a try. The book always talks about the rising cost of communication and management as more people are working on the same thing, which always sounded too abstract for me to fully grasp. Yes, it made sense, but I didn’t connect to it.
To my astonishment, in those 2 days I saw the complications of communication jam our work:
The cost of mind-share
During those 2 days I, as the developer that knew most of the code we were working on, had to constantly stop whatever I was doing to help someone else. Every 10 minutes someone came up to me to ask what a certain task meant, what might be the best way to do X, do I know what causes Y to happen and just plain syncing up. It’s obvious that I couldn’t get into a proper flow of development, which effectively already canceled out one developer.
More than the trouble I had trying to get some code written, my teammates were having different types of trouble too. First, they had to immerse themselves in code they were not familiar with in a fast pace. That includes having to grasp design choices of a constantly changing code base. Not having the time to go over all the other code that was being written, it was easy to open a file after 2 hours and see it completely different.
We also had to try really hard not to step over each other’s toes, and not to get dragged into merging conflicts. This meant that often you’d hear someone call out to make sure no one’s messing with class X and the likes.
And last, we had the trouble of hammering our “product owner” with tons of questions, often questions that he already answered multiple times earlier. This of course led to miscommunications and confusion.
After those 2 days
I sat down and blatantly said that as much as I like my fellow developers I’d be more than happy to stop receiving their “help” in this form. We returned to our previous formation and gladly got stuff done fast and with less talking and noise going around. It might sound funny but those 2 days were, for me, an excellent example of the exact point Fred Brooks was trying to make.