SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

To Build Better Software, You Need Fewer People (But Why?)

Posted by Bob Warfield on October 17, 2007

Mark Masterson reminds us that people have been saying for a long long time in places like the Mythical Man Month book that system design integrity is best achieved through the work of a single mind.  The alternative is design by committee, which dooms us to understanding by committee and all the inefficiency and waste that goes along with that approach.  The avoidance of premature optimization almost always improves architectures by making them more comprehensible.  Abstractions properly constrain the performance and functionality bottlenecks of a system to make them more comprehensible.  Yet how often do we really focus on making architectures or code understandable?  In what actionable way is that something you can measure and act on?

So far, the best answer is simply to use fewer people and live with what they can get done.  It will automatically lead to simplifications and abstractions that act as firewalls.  On the other side of the firewalls are initially very simple implementations, but they are placeholders.  Some chief architect decided an abstraction was needed so that there would be a place to stand with a big enough lever to move the software’s world should it be necessary. 

I vividly remember a seminar in grad school at Rice University.  Stu Feldman had come to visit us from Bell Labs.  To this day, he is best known as the creator of make.  When I asked him what made him invent it, he informed me that he was trying to make it possible for more people to work together on software.  In his view, communication between people was the arbiter of how many could work together.  Make, in conjunction with source control systems, simplified one area of communication so that people could work more or less independently on source files and they could all be brought together and made into a coherent whole for testing and delivery.  In Feldman’s mind, before make, only 2 or 3 could productively work together.  After that, he felt the number reached the 7 to 9 that human short term memory dictates as the barrier for efficient inter-personal communication.

Recently, I was talking with Peter Nickolov of 3Tera, and he echoed the sentiment.  They had to build extremely complex software that virtualizes data centers, but they did it with 10 or 12 developers.  After running many development organizations, Peter feels this is the optimal number for “magic” to happen, and that adding more after that will likely reduce productivity and result in a mediocre result.  I quite agree with him.  (BTW, I will be publishing an interview with 3Tera next week, so stay tuned–their technology is a “must-see” if you’re working on SaaS or Web 2.0 software!).

I’ve always kept the communication bottleneck and small team size ideas in mind, and found that groups take a profound dip in productivity when we get too far beyond 10 or so developers.  If a product can’t then be broken up into very independent modules with extremely simple interfaces between the modules, we are stuck.  The logical conclusion for development managers is they should pay inordinate sums for the very best athletes, because they will only get 10 or so working productively on a team.  The other logical conclusion is to invest in improving communication in any form possible. 

I like to consider the following as worthwhile communication investments:

– Wikis and other online sources that are easily searchable.

– Sufficient face time.  Working separately or at home is good for productivity drives, but you have to allow enough communication face time.  I like to create a frequent venue where people tell us what they’re working on, solicit feedback, and give demos.  Short self-contained development milestones facilitate opportunities to communicate and apply mid-course corrections.

– Screening for great communicators at interview time.  I like to run folks through a mock architecture review.  I have them choose some piece of software they’re proud of and present it to the group.  I think this matters a lot more than impromptu brain teasers and the other ilk one sees in some interviews.

– Focusing on team chemistry.  Some managers think their job is to put as many IQ points in the room as possible.  I think it is to assemble a group of people that love the idea they’re working on and love working with the team they’re on.

I’ve put all this into practice for a long time, and gotten excellent results.  James Coplien wrote a paper about the amazing communication patterns that existed on my Quattro Pro team at Borland.  We had 8 developers, and we recorded some of the highest productivity scores that Coplien had ever seen.  As Coplien puts it when he introduces himself:

I’m one of the original Hillside pattern guys.  They brought me on board because of my earlier work on C++ Idioms:  C++ microarchitectures that I collected into one of the early (1991) C++ books. As I was finishing up that C++ stuff I was just starting work on organizations. It started with a study of the Borland Quattro Pro for Windows project. The ensuing DDJ article was a shot heard round the world. It was one of the foundations of SCRUM and became the foundation of the organizational patterns efforts. The organizational patterns work started appearing in 1993 and would become a foundation both of XP and the Agile movement.  

I’m proud to have contributed to the early ideas that led to the more mature methodologies of Scrum, XP, and Agile programming, but it all boils down to a simple observation:  It’s all about getting fewer, more talented people to work really well together as a team.

Related Articles:

Alex Iskold talks about some of these issues, and some of the newer developments like Design Patterns and Refactoring.  In the end, he agrees on the fewer better developers conclusion.

Raganwald asks, “What if powerful languages and idioms only work for small teams?”  Even crappy languages and idioms only produce much for small teams.

18 Responses to “To Build Better Software, You Need Fewer People (But Why?)”

  1. […] SmoothSpan Blog wrote an interesting post today on To Build Better Software, You Need Fewer People (But Why?)Here’s a quick excerptTo Build Better Software, You Need Fewer People (But Why?) Posted by smoothspan on October 17th, 2007 Mark Masterson reminds us that people have been saying for a long long time in places like the Mythical Man Month book that system design integrity is best achieved through the work […]

  2. […] the Universe? (Interesting Theory from Nick Carr)Wookey Leaves, Where Does That Leave Oracle Fusion?To Build Better Software, You Need Fewer People (But Why?)70% of the Software You Build is Wasted (Part 1 of Series of Tool/Platform Rants)Who Doesn’t Love […]

  3. Is Agile the Future of Software Development?

    Alex Iskold writes about the Future of Software Development at Read/Write Web. There he makes a few nice points comparing the waterfall model to today’s more trendy and talked about agile processes. He doesn’t get into the various other sof…

  4. Link love…

    Wide Finder, Stacks of Lamps, and Virtualization | VMTN Blog
    To Build Better Software, You Need Fewer People (But Why?)
    Wow. Aloof and I seem to have hit a nerve with our conversation about lamps . Both of the responses above (the first from

  5. m1ngsheng said

    “how many cold work together” should be “how many could work together”

    Your assertions are mostly on the mark. More detail is needed around “sufficient face time” to be able to understand your reasoning. Why should we allow for face time?

    I like where you are headed with interviewing. Check out my partner’s thoughts Interviewing a Software Engineer.

  6. smoothspan said

    Face time improves communication, there’s no two ways about it. There are nuances of body language, and there is also serendipity, e.g. water cooler chance conversations. Good communicators can actual feel the loss of bandwidth between face to face and say a teleconference.

    Hence, I like face time.

    Unfortunately, this flies in the face of remote development, but that really interferes with communication anyway, and why do we do it? To save money in many cases. As I’ve told more than a few people, good software isn’t that expensive to build. Bad software is the most expensive software you will ever pay for.



  7. engtech said

    so that explains everything that’s wrong with make. 🙂

  8. troywing said

    Totally agree with small team sizes. In my experience, always has been better.
    I’ve just started reading your blog so maybe I have missed something, but I would be interested in knowing your thoughts about Outsourced Development. It appears from this post, it would not support your ideas around face time.
    And utilizing an iterative methodology like scrum with an outsource team?

    Troy Wing

  9. smoothspan said

    Troy, you’ve hit the nail on the head, but I would use a slightly different word: Offshoring. You can bring consultants onsite to facilitate communication, and I’ve done so with good success.

    Offshoring, OTOH, radically interferes with communication. That is not to say there is no place for offshoring or that you can’t be successful. But I don’t think you can split one of these small teams too easily across oceans without damaging communication. Accordingly, you have to take a lot of steps with offshoring to offset that damage. Examples I’ve heard of or used:

    – Spend money to fly people for face to face time.
    – Start the offshore group onshore for a while until they’re totally steeped.
    – Give the offshore group an independent module that requires minimal communication.
    – Invest much more heavily in communication oriented process and tools.

    All of this costs money which offsets the offshore cost advantage. The good news is that there are a lot more tools such as Wikis and others these days to facilitate communication.



  10. bjacaruso said

    Small groups are the key to our success. We have tried large groups, we have also tried offshore. But as Ben mentions the communication is difficult. Flying people in from time zones away is not always feasible. The offshore idea was less expensive in terms of short term expenditure. But the communication hurdle was a difficult one for us to over come. We even tried video conferencing, but we could never seem to build the momentum required to deliver successful projects consistently.

    The team I currently work with has 7 people. We meet frequently (several times a day), face to face. Ideas that are started over coffee are finished at the white board. Problems are communicated in common areas and solved in spaces with as many as three people working on the solution. Lunch is a meal to share; both ideas and solutions.

    One thing we have learned is there also has to be some where to go for a refuge from the community. Our offices have doors on them, when they are closed (which is not often) they are respected.

    But the idea of collaboration between a small group has worked well for us.


  11. smoothspan said

    Bjacuruso, your comments on offices are interesting in this age of egalitarian cubes for everyone. I’ve tried both.

    At Borland, it was part of the culture that every developer had their own office for privacy and to facilitate concentration. I think that there were tangible benefits, but I don’t have enough data to say whether it was worth the cost or the issues with the rest of the company who did not have offices thinking developers were prima donnas.

    I’ve seen the opposite extreme, including a couple of companies where the CEO got a cube, Andy Grove style. On the latter, it is my observation that all the execs had private “conference rooms” and were mostly seen in the conference rooms, which seemed to me like cheating.

    There is a middle ground that worked well for me at a startup. The space we took had a lot of offices so we paired up engineers in the offices. This actually seemed a great compromise.



  12. […] Posts Multitenancy Can Have a 16:1 Cost Advantage Over Single-TenantTo Build Better Software, You Need Fewer People (But Why?)A Pile of Lamps Needs a BrainiPhone, iTouch, iTrojanHorse?SaaS, Cloud Computing, and Liability for […]

  13. […] Posts Ubiquitous Social Networks for BusinessHow Will This Web 2.0 Bubble Burst?To Build Better Software, You Need Fewer People (But Why?)Multitenancy Can Have a 16:1 Cost Advantage Over Single-TenantUser-Contributed Data […]

  14. […] Innovation CycleOne Cloud, Two Clouds, Four Clouds, More?Serendipity is the Key to Code ReuseAboutTo Build Better Software, You Need Fewer People (But Why?)Software Companies Push Service Because It’s the Poor Man’s SaaSLack of Good Platforms is Stunting […]

  15. obsequium said

    This sounds a lot like the law of diminishing returns in economics.

  16. […] and this assertion is rather consensual. Bob Warfield stresses in his earlier post that "small talented teams crush big teams" not only with regard to productivity but also in quality terms. According to Guillaume who […]

  17. […] I read this on InfoWorld’s Zack Urlocker’s post where he discusses Bob Warlfield’s blog post “To build better software, you need fewer people“. […]

  18. […] Having fewer developers and a good strategy should result in better products. This is the same conclusion that Bob Warfield came to in his article titled "To Build Better Software, You Need Fewer People (But Why?)". […]

%d bloggers like this: