How Big Should a Dev Team Be? Smaller Than You Think…
“What one programmer can do in one month, two programmers can do in two months.” –Frederick Brooks, author of The Mythical Man-Month
I don’t care what tech you are using, or how “big” your project is… Your development team should start small. Always. And most of them need to stay that way, too.
Yes, even for enterprise software. Or big complicated government systems. What matters is not the size of the project, but the complexity of the code. (And honestly, for most projects, the code does not need to be all that complex.)
The idea here is not a new one; it was captured by Fred Brooks in the 1975 book The Mythical Man-month and by Kent Beck in Extreme Programming Explained in 1999. Still, there have been recent examples in the news demonstrating that people still seek overly big solutions to small problems, simply because they have a big reach or spread.
So I am offering some examples of my own, along with an explanation of how work scales. Know how an effort scales and you’ll know whether it makes sense to get a big team.
Development is Less Like Mowing a Lawn, and More Like Composing a Song
Some activities scale with the size of what you are dealing with. Some don’t scale with size; they scale with complexity. Bad things happen when those two things are confused.
Take mowing a fairly large field — say, an acre big. Start with one person tasked with this job.
Once the mower is started, it takes a certain length of time to cover the entire area of the field. But now add a second person, one person starting at each end. Mowing the field now takes half as long (assuming they mow at roughly the same rate, of course). Double the number of mowers again, and again you cut the time it takes in half.
This is because the time it takes to mow a field mostly depends on just one variable: How big each person’s portion of the field is. Double the field, you double the time. Add more workers, and the time goes down. The task scales with size. (Spoiler: Programming is not like that.)
Now compare that with composing a song — the tune, the lyrics, the beat, etc. Even if there is a set time in which one person can do it (and let’s be honest, there never is), that time does not halve by adding a second person.
Why? Because those two people cannot just work independently on their tasks. If the first person, say, decides to make a change to the beat, or add a refrain, or decides that the boy-meets-girl theme needs a verse from the viewpoint of the ex-girlfriend, those changes will have ramifications that reverberate through the piece. They will ultimately affect what the second person does, and vice-versa.
This is why the two songwriters will have to collaborate. They will need to work back-and-forth, in something close to real time, to make the song gel as a whole. They can’t just work independently towards the same goal, as our mowers do. They need to interact, find common ground, and get feedback.
(This is why we have the image of the lone artists. Sure, there are songwriting duos, but these are people who have worked hard to build a good collaborative relationship. It’s even rarer to see trios or more. Every time a person is added to the project, you increase the amount of effort that needs to go into communicating and collaborating. The amount of non-songwriting work goes up, but the “work done” on the song stays the same.)
Developing a piece of software or new technology is more like songwriting. Yes, the dream is to tell one developer to work on this part, tell another developer to work on that part, basically breaking one large task down to smaller tasks. But that dream almost never becomes a reality. In practice, every person added to the project adds to the non-coding work that needs to be done. Put too many developers on a project, and it virtually grinds to a halt — just as having a few dozen songwriters work at the same time will never produce a commercially viable song.
An Example in the Wild
Not too long ago I wrote about government projects for developing vaccine scheduling software that was, in essence, no-bid contracts that went to very big corporations. I have nothing against those big corporations, but I was a little shocked at the price tags attached to projects that were, all said minor league stuff.
The proof that they were minor league came when the apps were unusable and so some states… decided to use Google Forms instead. That’s how easily the problem was solved.
So why the huge price tag? Probably because the government assumed this was a big, important project (and it was). But the development firms followed suit, trying to make a solution that was also big. And they likely threw hundreds of developers at it.
Assuming that you need a $14 million piece of software, coded by hundreds of people, because you have to schedule millions of vaccinations is lawnmower thinking: I have a job that is this big, so I need to throw this many people at it. That’s the kind of thinking that will land you in trouble.
Creating software like this is clearly a songwriting problem. It doesn’t matter if five people listen to a song or five million: The process for creating that song is what it is. And putting hundreds of people on that process won’t make it any better.
Why Smaller, More Nimble Teams Deliver Better Value
I would usually say “why smaller, more agile teams deliver better value,” but I don’t want to bias the discussion here. Suffice it to say that, when you cut down on the cross-communication needed, you can often get to a minimal product more quickly. Once you have that, it’s easier to get feedback, revise, and retest. Smaller teams can also deal with changes in a direction more easily, and are more likely to inspire their members — they tend to “riff” off each other, instead of getting defensive about their one little corner of the project.
My advice? Never start a development project with a large team. And don’t add more programmers to a late project thinking it will suddenly get “back on track.” It probably won’t. Empower a smaller, nimbler team instead.
👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.
Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬
