Editorial Note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, take a look at NDepend and see how your code stacks up.
Over the last few years, I’ve had occasion to observe lots of software teams. These teams come in all shapes and sizes, as the saying goes. And, not surprisingly, they produce output that covers the entire spectrum of software quality.
It would hardly make headline news to cite team members’ collective skill level and training as a prominent factor in determining quality level. But what else affects it? Does team size? Recently, I found myself pondering this during a bit of downtime ahead of a meeting.
Does some team size optimize for quality? If so, how many people belong on a team? This line of thinking led me to consider my own experience for examples.
A Case Study in Large Team Dysfunction
Years and years ago, I spent some time with a large team. For its methodology, this shop unambiguously chose waterfall, though I imagine that, like many such shops, they called it “SDLC” or something like that. But any way you slice it, requirements and design documents preceded the implementation phase.
In addition to big up front planning, the codebase had little in the way of meaningful abstractions to partition it architecturally. As a result, you had the perfect incubator for a massive team. The big up front planning ensured the illusion of appropriate resource allocation. And then the tangled code base ensured that “illusion” was the best way to describe the notion that people could be assigned tasks where they didn’t severely impact one another much.
On top of all that, the entire software organization had a code review mandate for compliance purposes. This meant that someone needed to review each line of code committed. And, absent a better scheme, this generally meant that the longest tenured team members did the reviewing. The same longest tenured team members that had created an architecture with no meaningful partitioning abstractions.
This cauldron of circumstances boiled up a mess. Team members bickered over minutiae as code sprawled, rotted, and tangled. Based solely on this experience, less is more.