Silence is Golden

It is a mostly well-known fact, yet nearly always overlooked, that large software teams underperform small ones. I’ve been building software professionally for 15 years and continue to be amazed by this simple truth. Fred Brooks, of course, canonized this thinking in his “bible of software engineering”, The Mythical Man-Month, but as Brooks has been known to say of his book, “everybody quotes it, some people read it, and a few people go by it.” The urge to add bodies to expedite software development is just too strong to resist.

This isn’t surprising. It’s human nature to apply learned patterns to problems. You need to build a stone wall to defend your town? Add labor (preferably slave) and the project pace quickens. Trying to hunt a bison? Get all of the able-bodied men to assist. Work, broadly defined, is a function of man-hours. The more men, the more man-hours are chewed-up per day, and the faster we all finish and go home.

Unfortunately, software development works precisely the opposite. Throw more people at an effort and the pace drags. And once the pace drags, the human instinct takes over and the urge to add “resources” to an effort takes off – thereby slowing it down further. Brook’s Law is a law for a reason, it’s like gravity—try as you may to overcome it, you’re going to get pulled down.

So why is this the case? At the most basic level, it’s of course about communication. More people require more communication. Think factorials. Communication isn’t inherently bad, but it’s time consuming and fraught with inconsistencies and errors (but Tom told me that feature was taken out of this version of the app). It’s also about decision-making. Larger teams often have more than one decision-maker, which is deadly. Show me a medium to large scale software development effort with more than one decision-maker and I will show you a future disappointment.

OK, so if communication and shared decision making are at fault, then the optimal team size for a development effort is one, correct? Well, sort of. One talented designer / developer with an innate understanding of the product they are trying to develop is the optimal team size, yes. (Chris Dary from Arc90 is one example of that – he single-handedly built the first version of Kindling and took it from idea, to prototype to beta version in weeks. No debating features, no iterating on logos (make it bigger!), no defending decisions.) However, you probably recognize a logical constraint with this, which is that these people and conditions are very rare, and software development, like every other human endeavor, is becoming more and more specialized. It’s hard to find all of the required skill in one human – a product visionary that knows javascript frameworks, can configure apache, design interactions and write SQL. So let me rephrase the optimal team size for any software effort:

The optimal team size for any software effort is precisely enough people to cover all of the required skills of that effort and not a single human more.

Follow this rule and you will be optimally positioned for success 100% of the time.

Besides reducing the team size down to the bare minimum, are there other things you can do to resist the tug of Brook’s Law? Thankfully, there are:

• Have a fully empowered single Product Manager. This is probably the most controversial. Years ago after reading the (must-read) Dreaming In Code, I wrote this:
  

  Good software requires a singular vision, and a singular keeper of that vision. The Chandler effort was plagued by ambiguity from the start, what were they building? Did anyone know? Did all of them have the same vision? Any successful software efforts that I’ve been a part of had either a benevolent dictator, a less-than-benevolent dictator or a team with a shared brain. Another manifestation of this is the fact that often great software is built by a team of one – where the vision is never lost in the details of communication. Even worse for the Chandler team, not only did the team not have a shared vision of what they were striving towards, it seemed that no individual did either. Rosenberg articulates this point perfectly later in the book:

  “…software development takes simple elegant visions and atomizes them, separating them into millions of implementation details and interface choices and compromises. The art of making software well is, in a sense, the ability to send a vision through that atomizer in such a way that it can eventually be put back together…”

  A good litmus test here would be to walk around and talk to your software team, asking each member what they’re building. Force them to describe the vision, not the details of a specific task. If you hear entirely different things from the team, you’re likely in trouble.

  That comment received the most feedback, as people were uncomfortable with the notion of one decision-maker. But I believe that even more today than I did then.

• Document versus communicate. This is a lesson I’ve learned over and over. Communication and discussion is fine, but once a call is made, immediately capture it as fact. That might be in a Requirements Document or better yet as a ticket in an issue tracking system, but don’t leave decisions floating in the ether. Decisions are gold, when you arrive at one, treat it as such.
• Design first, build later. And I don’t only mean wireframe and comps, I mean design everything before writing code. The architecture. The API. Whatever can be thought-through ahead of coding pays dividends later. This is such an obvious and straight-forward fact that I see ignored repeatedly. Design is decision-making and arriving at decisions early is the goal. Having a fully documented and stubbed API, for example, represents tens of hours of thinking and hundreds of decisions that, once in place, empower development teams to build without communicating with each other. And communication is the enemy of productivity.
• Use good issue tracking. It’s almost 2011, get yourself a decent issue tracking system. Imagine a fireman using a dull axe or a painter using worn brushes. Building software is an exercise in communication and the issue tracking system is where nearly all of this communication plays out. That’s how important it is.

But the absolute, don’t-forget-it, most important thing is team size. The optimal team size for any software effort is precisely enough people to cover all of the required skills of that effort and not a single human more. Ignore this at your peril.