undefined | Better HN

0 pointsdpark2mo ago0 comments

> If you’ve heard it a number of times and refuse to consider what people are saying then maybe I can’t help you.

What someone says “I’ve heard this a thousand times, but…”, it could be that the person is just stupidly obstinate but it could also mean that they have a considered opinion that it might benefit you to learn.

“More people slow down projects” is an oversimplified version of the premise in The Mythical Man Month. If that simplistic viewpoint held, Google would employ a grand total of maybe a dozen engineers. What The Mythical Man Month says is that more engineers slow down a project that is already behind. i.e. You can’t fix a late project by adding more people.

This does not mean that the amount of code/features/whatever a team can produce or ship is unrelated to the size of the team or the speed at which they can write code. Those are not statements made in the book.

0 comments

3 comments · 1 top-level

agentultra2mo ago· 2 in thread

Sure, I’m not writing a whole critical analysis of TMMM here and am using an aphorism to make a point.

Let’s imagine we’re going to make a new operating system to compete with Linux.

If we have a team of 10 developers we’re probably not going to finish that project in a month.

If we’re going to add 100 developers we’re not going to finish that project in a month.

If we add a thousand developers we’re still not going to finish that project in a month.

But which team should ship first? And keep shipping and release fastest?

My bet would be on the smaller team. The exact number of developers might vary but I know that if you go over a certain threshold it will slow down.

People trying to understand management of software projects like to use analogies to factory lines or building construction to understand the systems and processes that produce software.

Yet it’s not like adding more code per unit of time is adding anything to the process.

Even adding more people to a factory line had diminishing returns in efficiency.

There’s a sweet spot, I find.

As for Google… it’s not a panacea of efficiency from what I hear. Though I don’t work there. I’ve heard stories that it takes a long time to get small changes to production. Maybe someone who does work there could step in and tell us what it’s like.

As a rule though, I find that smaller teams with the right support, can ship faster and deliver higher quality results in the long run.

My sample size isn’t large though. Maybe Windows is like the ultimate operating system that is fast, efficient, and of such high quality because they have so many engineers working on it.

dparkOP2mo ago

> using an aphorism to make a point.

But your “aphorism” is not true. You made a claim that more developers make a project slower. And you pointed to TMMM in support of that claim.

Now you seem to be saying “I know this isn’t really true, but my point hinges on us pretending it is.”

> Let’s imagine we’re going to make a new operating system to compete with Linux.

This is a nonsensical question. “Would you rather be set up to fail with 10 engineers or 1000”? Your proposed scenario is that it’s not possible to succeed there is no choice to be made on technical merit.

> But which team should ship first? And keep shipping and release fastest?

Assuming you are referring to shipping after that initial month where we have failed, the clear option is the largest of the teams. A team of 10 will never replicate the Linux kernel in their lifetimes. The Linux kernel has something like 5000 active contributors.

> I’ve heard stories that it takes a long time to get small changes to production.

There are many reasons it’s slow to ship changes in a company like Google. This doesn’t change the fact that no one is building Chrome or Android with a team of ten.

agentultra2mo ago

You’re right, I’m not making my point well.

You do need enough people to make complex systems. We can do more together than we can on our own. Linux started out with a small team but it is large today.

It runs against my experience though and I can’t seem to explain why.

My observation in my original post is that I don’t see why writing code is the bottleneck. It can be when you have too much of it but I find all the ancillary things around shipping code takes more time and effort.

Thanks for the discussion!

1 more reply

j / k navigate · click thread line to collapse