There's just too many people in tech, because tech needs too many people. Once we have better tools to reduce complexity and allow teams to be much much smaller, many of these problems will vanish, because a engineering team will consist of 1-3 wizard engineers who control all aspects of the tech. We simply do not need to have teams as big as they are, for what we're ultimately doing.
Yes, more engineers working on the same problem = slower time to actually releasing anything. Unless you can find a way to divide the task into parts that don't impede the others, adding more people will make things take longer time.
Software projects at least don't scale linearly, doubling your 3 man team doesn't double output. It's not a stretch to say that having 10x money and manpower won't scale your engineering project that far, and may even hurt it as you add managerial layers and politics.
adding more people to a project will most of the time make things worst, I'd rather work with 2 very competent people than having a team of 20 mediocre ones.
Three is probably a good number, if they are decent engineers. Throwing more people at a problem has diminishing results very, very quickly in software, unless the project can be broken down into mostly independent teams. Even then integrating the work into something coherent can easily be more challenging and time consuming than just having a tiny skilled team own the project soup to nuts.
Unfortunately I'm pretty sure he's right. Large orgs doing projects with 30-40 engineers... don't get anything done. But people somehow have the belief that 30-40 engineers is what it takes, whereas 3-4 ones would get it done faster, although with a lot less of the details polished off. But in a quarter of the time.
What do you question about it? The point of the specific essay was that the work of development/engineering cannot be sped up linearly by adding people. You still see this attitude with managers today: The team of 5 is running behind, let's put that other team on the same project, now it's 10 people. But those 5 new people:
1. Don't know the code base or problem domain. So they'll spend months getting up to speed.
2. Will increase the communication overhead (now each person has to coordinate with up to 9 others, not just 4).
On the small scale of this example, you may see good results. 5 more people isn't a huge amount of communication overhead, and if they're experienced (perhaps even formerly worked on the same or similar project) then you'll see an immediate drop in productivity and then a quick rise back to the new baseline. But will that hold with another 10 people? 20 more beyond that? Each doubling will not continue to halve the time to develop the project, there are limits, and at some point the returns will be negative. The additional people will slow it down. Not just the initial slow-down, but also the new baseline after things settle will be lower than before adding them.
Realistically, I don't think you can have a minimalist, clean and focused code base with thousands of engineers pounding away at the keyboard. You ought to make some trade offs with that many employees.
Yap, I’m leading a project that could use more engineers (just two of us) cuz it’s going to be tight to hit an upcoming scaling deadline. But the thought of spending my time ramping up other engineers at this point doesn’t sound good.
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.
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.
The last assertion is problematic. A team of engineers can only produce so many pages -- you could reasonably need multiple teams to work on different parts of the product's UI.
I don’t understand why two teams means slower. Are you keeping the total number of engineers the same? If you are saying 2x engineers on electron complete tasks faster than 1x on electron and 1x on native, you are basically agreeing with OPs take.
You take money to provide software. But then you become lazy and greedy and want 1 size fits all. End result is your users having clunky, high latency experience.
This is effectively asking to double the size of the engineering team, or slow it down dramatically.
If I were a startup or small business, I'd rather ship a slightly slow-feeling app with my existing team of web developers who already know their tools, than to hire a bunch of native developers and somehow get them all on the same page.
reply