The Skeptical Methodologist

Software, Rants and Management

There are no ‘large’ teams

I read a lot of posts from others explaining their development methods, and many a humble developer makes an effort to note that what they do “probably wouldn’t scale” and “works great for a small team”.  What they mean is that their methods are great for 3-5 developers working together, but would start to fall apart when you, say, moved to a 200 person project.

Then you get these tool makers with ‘enterprise’ level support.  A tool might be a nice toy, but unless it works for ‘enterprise’ level companies, then we’re not interested.  There seems to be some resonance between this notion of an ‘enterprise’ and the large teams mentioned previously.

I have it on good authority from various sources I cannot recall enough to cite properly right now that one of the best measures of probable project success is the size of the budget and team.  Interestingly, this is an inverse relationship.  The larger your team, the larger your budget, the more likely you are to fail.

I believe we’ve become consumed with this notion that large projects need a lot of resources. But recall, only in an academic or research setting do projects actually fail for technical reasons.  In virtually all other settings, industrial and commercial, project failure is due to other factors.  Namely, coordination and communication, precisely things that do not scale with increased resources!

The reason our methods that work so swimmingly for small teams don’t seem to ‘scale’ is not that we haven’t had the chance to work in a more rigorous ‘professional’ environment.  It’s because nothing scales to that level.  That’s not to say large projects cannot succeed, but instead to say that the best thing you can do to a large project is to take people and resources away until it is a small one.

There are a few reasons I’d throw out there, such as communication overhead, which I’ve already mentioned.  Mentioning just those tempts our PHB’s to think that if they just held more meetings they would increase communication.  Or perhaps they could mandate another 500 pages of documentation per function.  When it comes to coordination issues, perhaps the solution isn’t shrinking budgets and org charts, but instead keeping an iron fist control on everything and not letting a single decision be made without your input.  Surely that would keep things coordinated, right?

Sadly, in addition to communication and coordination overhead, we have Fred Brook’s idea of Conceptual Clarity to deal with.  Conceptual clarity is the idea of a clean, well understood design entirely within the head of a single person.  When a single person builds a system, there’s a clarify of thought and motive that is evident in nearly every single design decision made in the system.  When you break that system apart across multiple people, that clarity is reduced.  When you break it apart more, clarity all but disappears.  We have tools, techniques and methods that attempt to improve this clarity, such as code contracts, encapsulation and other forms of information hiding.  These at best scale at O(log(n)).  They’re great techniques, you should of course use them, but they aren’t going to allow you to increase your roster from 10 developers to 100.

Takeaway: Small project methods don’t apply to large projects.  This is because nothing applies to large projects.  The lesson here is that small is beautiful, avoid project growth like the plague.


December 13, 2010 Posted by | Uncategorized | 1 Comment