I'm honestly not even super convinced that small teams struggle to maintain large systems. I've been on a team that was only 7 good engineers maintaining a 3.5 million line project that had both a web UI and thick client. It supported 2 different databases and had a horizontally scalable job runner.
At one point it was 35 engineers, but layoffs took it down to 7, at which point we started to get a lot more done. There was just so much less time spent keeping everyone aligned. So many fewer meetings, sign-offs, reviews, plannings, retrospectives, management meetings, etc. Developers had a lot more agency, so they just got stuff done. Technical debt repayment became 50% of our time, as we easily knocked out features in the other half of the time. We kept ruthlessly cutting complexity, so it got faster to add new features.
I'm sure some projects just need more bodies, but I think there's an upper bound to how much complexity can be added to a system in a given unit of time. Adding developers over a threshold will result in the same amount of features per week, just everyone does a little less and spends a little more time on communication.
Repeat up to thousands of developers where adding a single field takes months.
I have a mild critique of this: Small teams can get a lot done, and there certainly is a diminishing return per extra developer on any team, but most development isn't slow because it has too many people but rather the problem being solved has become large enough that a small group can't keep all of it in its head.
Eventually, those three programmers have built so much that even with their productivity, their entire time is spent on maintenance. Replace 3 with N programmers, especially understanding the diminishing returns.
Then take into account that if one experienced programmer leaves a small group, picking up that domain knowledge takes a significant amount of time. While having a team of 50 makes each engineer slower, it means that losing one or two isn't a company-altering event.
Small teams can be super productive, but unless the people in it are there for the full run of a product, you'll end up with a problem; taking over the work for one developer will take more than one developer.
I'm sure - but haven't witnessed this myself yet, so take it with a grain of salt - that if one productive developer builds an application in a year, it needs a team of 5-10 to continue development at a similar level, and even then it may not make it.
Companies need to focus on keeping software as simple as possible, well documented, and transferable. Unfortunately this also means curbing people's enthousiasm.
I think it truly is harder to manage larger numbers of people - absolutely requires skills that aren't so critical in a small team. There's too much complexity to micromanage so for one thing you need to be good at picking out leaders who can help you keep on top of it all and you need to lead them to solutions without being able to dive into the details like you might have as a developer. I think it's bloody difficult and I'm only one level up now.
That said, I also think some people like to make solutions overly complicated which ends up requiring lots of people. In some companies the simple solution (e.g. django and postgres) isn't seen as "enterprise ready" or whatever. So they end up with lots of people on something that could have been done more simply with 2-3. Then maintaining that takes lots of people and then everyone in the team has an interest in keeping things as complicated as possible - in selling the "we will need it one day" idea.
That also combines with impossible tasks - like "lets rewrite the complicated slow old system while keeping on adding features to it" and so on. Then there are never enough developers to do the impossible task - especially as the rewrite turns out to be complex and have issues too.
Building an application is easy. Maintaining it, adding features, scaling it, integrating with other services, building platforms… those activities all take a lot of other work.
I work at a small company whose core product was developed primarily by one or two developers. We now have substantially the same functionality with an engineering team of ~13, but constantly have a huge amount of work we want to do. Things like scaling, refactoring legacy code, paying down technical debt, handling complex and tricky edge cases that could previously be glossed over, and building administration tools – these take up _phenomenal_ amounts of time, especially if you want to work at a sustainable pace. I can totally believe that larger software houses need a surprising number of engineers.
Yes. I think one of the interesting things in software is the irrational amount of productivity that a small team can accomplish, but that it can only be done by doing things in a way that can never be executed by a 50 person team.
So it is possible for 3 - 10 developers to maintain a product that perhaps, would need 50 developers using fully maintainable methods. But the 3-10 developers can never produce what 500 developers can. And there's a valley of death between about 10 and 30 where you actually go backwards. With 20 developers you might accomplish less than with 10 unless you very carefully and strictly compartmentalise the team (at which point you have two teams of 10 developers that don't interact ...).
To be fair, teams scale extremely poorly. I'd almost always expect a smaller team to be on par with or even outperform a larger team, even double in size.
You get both steep diminishing returns from adding more devs, you also get additional overhead from needing more management.
200-2000 person projects may be what the big guys do but that does not mean it's a good idea. There's bound to be massive inefficiency with large numbers of developers working on the same project. The resulting software will reflect the complicated political structures required to organize that many people and will suffer greatly for it. Small teams are the most successful at producing quality software in a reasonable time frame regardless of problem complexity.
> Having a smallish team makes it possible (although not easy) to have a team that are all high performers. And that team can easily outperform one 2x-5x as large if not more, because there is a large communication overhead to scaling to more people.
^ This. As the project gets larger you can't find enough "star programmers" in a timely manner and have to fall back to mediocracy. Read "The Mythical Man-Month" and the associated Brooks' Law for context.
There are also cases where small teams that have grown grow unproportionally to the size of the product, and while the product is set up in a fairly sane way (and there is little wrong with it!) having 20 fresh people swarm into it destroys both the architecture and the execution. And with a small team enforcing cohesion for both of these is much easier! So a small project might as well stay small, but this should be somewhat a priority.
Teams beyond a certain size seem to require some intermediate artifacts. (Bill Joy described an ideal-sized team to be the number of people who can sit comfortably around a dinner table: so 3-6 is fairly perfect for his definition.) It seems like small teams can just keep each other in sync with quick conversations. They seem to be able to keep the design and requirements in mind at all times. Maybe it's the scope of what they're trying to solve or maybe it's some residual overhead that larger teams create due to additional communication "friction". I'm not sure. It's interesting though.
> There is a productivity valley between small teams (up to 5-8 people) and large teams (20+).
Sorry, but I don't agree with that at all. As soon as you have more than one person working on the same part of your code, you incur some degree of overhead. I don't see why the numbers 8 or 20 are special. Are you really claiming that a competent development team of 18 people cannot do more than a competent development team of 8 people?
To co-ordinate teams of many developers, we divide projects into manageable chunks, each with a relatively small number of developers working on them. This requires good abstraction tools, so that developers can see how their contribution fits into the larger picture, can work with the code written by others without having to know it in intimate detail, and can combine all the components into a complete product. Again, I don't see how this picture differs whether you have 8 people or 20 people, unless you're following some sort of surgical team model where you really are trying to get all of the smaller team working on the same code but most of them aren't actually writing that code at all.
I think the small team aspect is far more important than anything else. With two developers in a startup, you can split up key components and have quick informal talks concerning design choices. In a real company, huge amounts of time are wasted on all-staff meetings, team meetings, 1:1 meetings, management fads, mandatory compliance trainings that come up quarterly and take hours, and the sheer human problem of coordinating that many people. Big companies have huge waste stemming from many different areas. For example, at a large company they have people in charge of requirements that have no understanding of the domain or how to write software. It's like the telephone game you get as a kid where the message completely changes by the time it gets around the circle. Of course you could have your devs do that job, but most companies simply aren't that logical. I bet Paul Graham and another competent developer could use a language that is not considered to be very productive (Ex: C++) and still swim circles past a large IBM team that is being held down by it's own weight.
Good point. I guess it boils down to team size. If the team size is large then the code is more likely to be refactored in stages than rewritten. And more people on a team usually means more code reading than writing. Also, you have a higher turnover of people so onboarding cost is important.
Small team size means you don't have a lot of these problems.
Your impression comes from the fact that you have not worked at larger teams, as you said so yourself. It's relatively easy to build something scalable from the beginning if you know what you need to build and if you are not already handling large amounts of traffic and data.
It's a whole different ballgame to build on top of an existing complex system already in production that was made to satisfy the needs at the time it was built but it now needs to support other features, bug fixes and supporting existing features but at scale while having 50+ engineers not step on each other and not break each others code in the process. 4 friends in the basement will not achieve more than 50+ engineers in this scenario, even when considering the inefficiencies of the difficulty in communication that come along with so many minds working on the same thing.
If small teams _always_ and _unconditionally_ are so much more efficient, why do we still have the likes of, say, IBM, Hyundai, Microsoft, or ant colonies?
I think that it partly is because large teams do a lot of things that small teams deem unnecessary, such as documenting design choices, pre-estimating demand/bandwidth requirements etc, making sure one complies with legislation, etc. Not all of that is necessarily waste.
Another large part of the difference, I think, is due to the difference between programming and engineering. Many small teams, especially at smaller companies, program, while almost all larger teams engineer. Programming produces way more functionality per man month than engineering does (for an example, read GNU's well-engineered hello world source code).
So, I think the main rule should be "only start engineering if you have to". Large team size is, for a large part, just a side effect of the decision to engineer.
Also, many companies and people seem to have forgotten (or never learned) that small teams outperform large ones. There is a point past which every additional person will make the project take longer, and result in lower quality.
> Small teams. And ones that work collaboratively, not ones that than carve the code up into bailiwicks so that they can mostly work in mini-silos.
Well, that may explain some of the difference between our points of view. Most of my experience is with medium (<20 developers) to pretty large (> 500 developers) applications. At some point, no matter how cooperative the team is, the amount of complexity that you can hold in your head is not sufficient to make sure that you're not breaking stuff during a simple-looking refactoring.
It's hard to have more than 2 developers working on the core of something. Development is a very non-concurrent activity.
Speaking from experience, when there's multiple people trying to take over the same bit, they only create conflicting changes all over the place and deadlock the project. It's worse than if no work was not done. Now somebody needs to take the lead and remerge things manually and discard what cannot be merged.
Regarding maintenance, the later army of maintainers is typically a bunch of contractors mostly sitting idle billing for time. The size of the maintenance team has little correlation to the workload.
At one point it was 35 engineers, but layoffs took it down to 7, at which point we started to get a lot more done. There was just so much less time spent keeping everyone aligned. So many fewer meetings, sign-offs, reviews, plannings, retrospectives, management meetings, etc. Developers had a lot more agency, so they just got stuff done. Technical debt repayment became 50% of our time, as we easily knocked out features in the other half of the time. We kept ruthlessly cutting complexity, so it got faster to add new features.
I'm sure some projects just need more bodies, but I think there's an upper bound to how much complexity can be added to a system in a given unit of time. Adding developers over a threshold will result in the same amount of features per week, just everyone does a little less and spends a little more time on communication.
Repeat up to thousands of developers where adding a single field takes months.
reply