If your software is late/buggy/whatever the solution is rarely adding people / process. It's usually removing people / process. Process is what allows managers to fuck up projects.
hell yeah.
http://www.youtube.com/watch?v=My-P4LssMsI
It seemed appropriate.
I agree with the parent comment. "Just programming" looks nice on a manifesto, but you need processes when you want to scale.
If you are working with 500 programmers, they are likely to be mostly mediocre - the good ones would have run away screaming to better jobs.
Sure, if you have 500 mediocre programmers, you need to rope them in with systems. If you hire 5-10 great programmers, stand well clear and let them do their job.
I've worked on very large software systems before, places that had around 1,000 developers spread throughout the organization. While there were a lot of mediocre, and truly some flat out bad developers, I guarantee you that 5-10, or 10-20 great programmers could have developed an equal system.
Throwing bodies at a deadline doesn't usually work. Throwing bodies at a problem can help, though.
Places with 1,000 developers spread throughout are working on hundreds of interacting projects. But, the communication and coordination isn't between all 1,000 developers.
And yes, I did well actually you.
Linux is a monolithic kernel, and because kernel parts depend on one another, unfinished changes are often blocking other changes and/or are breaking other parts.
Of course you aren't going to have 1000 developers working on the same line in the same file.
Linux is a product by itself, not a distribution of independent parts. You either have the whole kernel, or you have nothing. And I would die to see another kernel developed by 5 people, achieving the same feature-parity / stability and all that jazz as Linux.
the communication and coordination isn't between
all 1,000 developers.
Here's an example: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c...
Having all those 1000 developers talk to one another would solve all problems, but this is a problem of scale which processes solve to a certain extent. Your opinion also highlights what's wrong with software development as a whole -- you seem to be under the impression that you can go and hack stuff in a vacuum, without interacting with others.
[Piling] bodies at [the door] can help, though.
FTFY.
Beyond ~7 people, someone needs to begin to coordinate, which is the logical introduction of management and process. But again, avoid large teams where possible.
Linux, Windows, Microsoft office - all great examples of a huge number of modules working together. For instance, the programmer writing the font rendering doesn't need to work closely with the video driver developer, they interact through a carefully designed interface.
But if you are in a startup, odds are you are slinging many large libraries and iterating quickly on new code (that often only you consume). In that case, you're better to "Program, Motherfucker"
It's a business decision - is it cheaper to hire one genius to produce something amazing or to hire a few mediocre programmers and manage the heck out of them to produce something that just about works?