this post was submitted on 11 Nov 2024
769 points (98.4% liked)

Programmer Humor

32715 readers
699 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 98 points 1 month ago (3 children)

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.

[–] [email protected] 41 points 1 month ago

“What one programmer can do in one month, two programmers can do in two months.”

[–] [email protected] 7 points 1 month ago (1 children)

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

[–] [email protected] 4 points 1 month ago

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.