4 ms·
I saw your comment and laughed, then realized you were serious. If you are working with 500 programmers, they are likely to be mostly mediocre - the good ones
by gridspy 16y ago
I saw your comment and laughed, then realized you were serious.
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.
- jordan0day 16y agoI've struggled with how to respond to your comment. You seem to be taking the view that any project that requires more than 5-10 great programmers is inherently flawed. I think this is false. 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.
- quadhome 16y agoWhat single project requires more than 5-10 programmers? 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.
- jcitme 16y agowww.linux.org/
- dalore 16y agoIt is GNU/Linux thank you.
- krakensden 16y agoDistributions are GNU/Linux. The Linux kernel is Linux. And yes, I did well actually you.
- kijinbear 16y agoThey don't all work on the same part of the kernel.
- bad_user 16y agoSorry, but that's one of the stupidest arguments I ever heard (not referring only to you, but also to the parent's parent that brought it up). 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.
- billswift 16y agoYour last line: "But, the communication and coordination isn't between all 1,000 developers." Deserves more than one upvote - in any successful large scale project, the programmers work in very small groups, often just pairs, and interact with other groups mainly through the code-base itself. I am tempted to say almost exclusively through the code. That is why open source works as well as it does; if management actually added much value, linux could not be as useful as it is. In fact, I suspect management often is a negative factor; when large commercial projects work it is the result of superior design, and their ability to maintain adherence to the design, which is when management does add value.
- bad_user 16y agoIf you're talking about "one product" which you want to sell, then build Windows or Microsoft Office with 5 programmers. the communication and coordination isn't between all 1,000 developers. No, it's worse. Teams usually don't know what the others are doing, leading to broken, blocked or half-baked features and work duplication. Here's an example: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html 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.
- numeromancer 16y agoThrowing bodies at a problem can help, though. [Piling] bodies at [the door] can help, though. FTFY.
- gridspy 16y agoI've placed a ceiling at 5-10 programmers, because most tasks can be broken into modules such that only 5-10 programmers are working on a module, with decent separation between modules. 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"