mouldy.org

For the most types of development, small teams of skilled developers - between two and four people - can be vastly more efficient than traditional, larger teams. Especially in the case of new product development, a small team can be significantly more agile and effective. Productivity can be improved again with the addition of assistants, or 'monkeys', that help with tedious jobs such as hand testing, graphic design, machine administration or simple coding jobs.

My vision of the ideal 'ninja' development team is three guys sitting around a round table. They're all passionate about their work. They're all experienced in the technologies they work with. They probably won't agree on everything (and will delight in arguing a case, even if it's silly), but they know when enough is enough and can make a good decision quickly. They know each other's strengths and weaknesses well. There's a certain 'vibe' to the team; the idea that their work is fun, it's a challenge, it's what they live for. Give them a seemingly impossible task, and they'll not only achieve it, but exceed all expectations.

It's hard to describe such a team until you see it in action; it truly is an eye-opening experience. I suspect that this vision is what Paul Graham was trying to reproduce with Y Combinator.

Why can these small teams get so much more work done than enormous corporate behemoths?

Small teams require each individual to take responsibility

A developer in a large team is vastly less visible than one in a small team. Think of places you've worked (or currently work) where there are large development teams. In a team of twenty, who's going to notice if one person doesn't do any work? Theoretically, the team managers should know - but they're probably too busy 'managing' to pay proper attention to a problem anyway. The ways a developer can make excuses for low productivity are endless - support requests, bug fixing, computer trouble, helping out the new guy. In a team of three, an unproductive team member will be extremely visible. More usefully, individuals in a small team are less likely to cause problems in the first place - there's tremendous social pressure to not 'let the team down'.

Small teams are unconstrained and free

There is no hierarchy, and work done by one person is less likely to affect the others in unknown ways. If someone wants to do something, they can just do it. Since they will have a better idea of what is going on in the rest of the team, they can use their judgment to decide whether a discussion is needed or not.

For a simple counterexample, witness the huge CC lists that you frequently see on corporate email discussions. "I want to add an option to the dialog box here. I'd better check with my manager. The UI guys can fix it up nicely. And the graphic designers might have to tweak that image. Marketing might need to update their materials." Blah blah blah. People don't even know who they might affect with a decision, so they ask everyone just in case. A small development team won't have that problem - and if they do, there's only a few people to ask and decisions can be made much more quickly.

Large teams labor under their own weight

In the worst (but common) case, large teams need to work slowly in order to accommodate their own size. Any feature additions or changes need to be approved by lots of people; hence the phenomenon of people within organisations who do nothing but read and reply to email all day. A large team must act slowly in order to maintain 'cache coherency', where any decision-maker actually has all of the information they need to make a decision and is in sync with everyone else. This is a very difficult state to achieve, since every individual developer is at some point a decision-maker.

If the project is too large and complicated for any one person to comprehend in its entirety, a likely outcome is that work will be duplicated - features will be implemented twice in slightly different ways, a single bug will be patched around in different areas of the system, inefficiencies will grow and the system will bog down. This is bad partly because it leads to expensive rewrites/patches/design changes, and partly because it wastes the effort of all involved. Then again, you can always hire more developers.

Small teams must be focused

A small team cannot afford to take on more work than it has resources. The excess simply won't be completed. Since they are intentionally resource-constrained, the scope of projects that a small team will attempt is much smaller. Considering that as project size increases, the rate of success drops rapidly, this is a good strategy to enforce.

Being constrained encourages innovation. When you see something that is a 'cool hack', what makes it so cool? Think of a graphics demo in 64k of storage, or a home-made CPU. The same results could be obtained with less skill in a less resource-constrained environment, but would that be impressive at all? Would any thought or care have gone into the design, or would it be the first idea that would work?

Small teams have their knowledge concentrated

Individuals in a small team are likely to know everything about their part of the software and have a good understanding of the other parts. Bad design will be discussed and fixed more rapidly; large teams may not even have the option of changing a design if the project is large enough.

It's not uncommon for developers in large teams to have to debug, modify or work on code that they've never seen before. This is a tremendous efficiency penalty; it may take a developer days to understand the code well enough to be confident modifying it. It's likely that their changes will have unintended consequences elsewhere in the system, leading to more debugging work down the track.

The money will last longer

Given a set amount of VC funding, what will give you better results in the long term: a small team of star developers, or a do-it-all team of 100?

Now, which one can you pay for longer?

This is less of an issue for VC-funded companies; usually, VC funding is used when a market opportunity exists now, but may not in a few years time. For most companies that don't have a bottomless pit of cash and a gun held to their heads, small teams will give better results, and lower running costs for things like office space, lawyers, administration, and insurance hassles.

If you're attacking an existing marketplace - such as online stores, or search engines - then you'll have more time to play with, and the innovation that comes from a small team will be essential. You'll be able to fund the team through several attempts at 'breaking in' to the market, reducing overall risk.