Basically, a team of 5-8 motivated developers can create high quality, medium complexity software extremely fast.
But if the project is just a little too complex for one team of devs and you need more people, then you’ll need a lot more people. And a lot more time.
Cause the more people you add to the project, the more overhead you have. Suddenly you need to pull devs off coding to bring new hires up to speed. You need to write documentation on coding style guidelines, hold meetings, maintain your infrastructure, negotiate with hardware suppliers, have someone fix the server room’s door locks, schedule job interviews, etc. etc.
Counterpoint: ‘The Brooks’s Law analysis (and the resulting fear of large numbers in development groups) rests on a hidden assummption: that the communications structure of the project is necessarily a complete graph, that everybody talks to everybody else. But on open-source projects, the halo developers work on what are in effect separable parallel subtasks and interact with each other very little; code changes and bug reports stream through the core group, and only within that small core group do we pay the full Brooksian overhead.’
It absolutely fucking BAFFLES me that Brooks’ Law isn’t known by every software manager on the planet.
I’ve quoted it so many times at work, even in engineering focused teams in at least two big tech companies. It’s not a concrete fact, but it explains why so many teams are hilariously shit at delivering software.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
Read “The Mythical Man-Month”.
Basically, a team of 5-8 motivated developers can create high quality, medium complexity software extremely fast.
But if the project is just a little too complex for one team of devs and you need more people, then you’ll need a lot more people. And a lot more time.
Cause the more people you add to the project, the more overhead you have. Suddenly you need to pull devs off coding to bring new hires up to speed. You need to write documentation on coding style guidelines, hold meetings, maintain your infrastructure, negotiate with hardware suppliers, have someone fix the server room’s door locks, schedule job interviews, etc. etc.
“What one programmer can do in one month, two programmers can do in two months.”
Counterpoint: ‘The Brooks’s Law analysis (and the resulting fear of large numbers in development groups) rests on a hidden assummption: that the communications structure of the project is necessarily a complete graph, that everybody talks to everybody else. But on open-source projects, the halo developers work on what are in effect separable parallel subtasks and interact with each other very little; code changes and bug reports stream through the core group, and only within that small core group do we pay the full Brooksian overhead.’
Source: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s05.html
Nice.
It absolutely fucking BAFFLES me that Brooks’ Law isn’t known by every software manager on the planet.
I’ve quoted it so many times at work, even in engineering focused teams in at least two big tech companies. It’s not a concrete fact, but it explains why so many teams are hilariously shit at delivering software.