Distributed development not contrary to "Mythical Man Month"

Every now and then I read challenges to Frederick Brooks' wisdom. Mr. Brooks is the author of the "Mythical Man Month" and other must-read writing for software developers and particularly for software managers. His insights solidify what software developers know already - software engineering is a different animal than traditional engineering disciplines. Skip down to the next section to get to the heart of this post, I'm going to sidetrack for a couple of minutes.

My Connection to Fred Brooks

I've had the pleasure of meeting Fred Brooks on a number of occasions. As an undergraduate and a graduate student at the University of North Carolina (UNC) many years ago, I had the privilege of having access to Mr. Brooks - a faculty member. Unfortunately, it wasn't until years later I realised the immense opportunity missed by not taking one of his classes and not spending more time learning from this icon of computer science. A very humble and unassuming person every time I met him, Fred Brooks was happy to answer my (retrospectively) stupid questions.

Distributed Development the antidote to the MMM ?

The latest attempt to circumvent Brooks's law comes from a well articulated blog from Assembla, a company offering distributed development services. I actually signed up for their free service a while ago and plan on using it for some personal projects. While checking them out recently while trying to get a Git master up-and-running I saw the article under discussion (link below). I'd like to thank Stuart for his convincing discussion on the benefits of Git during the speaker's dinner at No Fluff in Columbus.

Communication

From the assembla blog of Andy Singleton:

"I think that Brooks is fundamentally wrong about the cause of the
scaling problem.  He points the finger at communication problems.  If
you have N people working on a project, you have N squared
communication channels, and each person needs to spend more time
communicating.  Furthermore, if a new person tries to come into a big
project, they have to get a lot of information from a lot of different
people, so the ramp up time is increased." 

Andy goes on to attempt to debunk the communication problems in an open-source, distributed environment by saying that "code... tickets, blogs, mailing lists, and wikis" all help eliminate the communication compounding problem. I found some truth in his argument, but overall, I must disagree that these things help greatly flatten the communication curve. I think you can increase communication on larger teams by using code-as-communication and the tools mentioned. But it's fallacy to think that these tools can allow a software manager to add people to a project and gain a non-dimishing resource increment. Simply put, adding 1 developer to a 4 person dev team doesn't mean you'll get 20% more output from the team, it will be less, closer to 10% for an average developer. More on this later.

Dependency

Again from the assembla blog:

" I think the scaling problem is not a communication problem; it's a
dependency problem.  It's not necessarily true that when you work on a
bigger system, you need to do more communication.  However, it is
always true that you depend on more things, so you are more frequently
waiting for something else to get finished. ...

 From this point of view, you can see that open source projects have a
huge scaling advantage because all code is shared.  If someone is
waiting for a component, and they are frustrated enough, and talented
enough, they can just fix the problem.  The code is all shared, anybody
can build and fix any component, and the responsibility for critical
components can move around.  The answer to the dependency problem is
less hierarchy, and fewer official tool builders, not more."

This goes against my experience on software development complexity and specialization. Sure, I can go fix someone else's code that I've not worked on before. It's highly possible I'll introduce a bug in some subtle way (but wait! don't unit tests help protect against that!?). Besides, I don't want someone working on the Web/Swing portion of a project suddenly hacking on a complex fetch group issue with a JPA query - and vice versa. To maintain project velocity, developers need to specialize within a release cycle.

Understanding the Big Picture

My primary reason for thinking these tools don't necessarily help communication is simple: you get maximum bandwidth one-on-one. Also, as project size & scope increases, hence the need for more developers, the application becomes inherently more complex. Both size and complexity lead to more use of these tools, making it more difficult to find what a developer needs to get his job done, and the downward team productivity trend starts. This downward trend may be less due to using these modern tools and communication techniques, but there is a definitely no way to stop the downward trend. The only real solution is to break large teams into smaller subteams, which can introduce its own problems.

Please note that I do not see blogs, wikis, code-as-communication, etc as anathema. In fact, I think they are vital parts of a modern software team. They definitely help to maintain project velocity and allow for distributed development. They do not, however, replace the value of a daily SCRUM meeting, and one-to-one IM, phone calls, and "walking to someone's cube." One final note on communication tools: while physical co-location of a team is useful, it is not necessary in today's world. Using cheap phone/voip, video conferencing, and instant messaging can actually increase project velocity over the life of a project release. Developers need time to focus and concentrate; being in the same office with team members 5 days a week is unnecessary and counter-productive for this crucial need.

The point here is simple: there's no getting around Brooks's law. You can minimize the penalty you pay for growing a team. In my opinion, here's how this can be done:

• Hire the best people - getting 1 sharp developer who does 2X code at 2X quality beats getting 3 developers who do 1X code at 1X quality.
• Use the tools mentioned here to increase communication: wikis, simple bug tracking, etc. Just be prepared to spend resources maintaining them just like you maintain code - this means doing regular "cleanup" and updating to remove junk and increasing coherence.
• Increase productive time by removing distractions and providing rewards for development focus

The final note I'd like to make here is that the recently released "Productive Programmer" by Neal Ford helps enumerate the 3rd bullet point above. Neal's book succiently summarizes what great developers have been doing for years to be that guy that is "2X code at 2X quality."

Originally posted on The Artful Blogger