4 ms·

Not necessarily. I was once working in a large software project (500+ people), which went off-track, and then some added processes helped to save it, like for e

by greyman 16y ago

Not necessarily. I was once working in a large software project (500+ people), which went off-track, and then some added processes helped to save it, like for example continuous preintegration and more rigorous testing before each check-in. I agree with the parent comment. "Just programming" looks nice on a manifesto, but you need processes when you want to scale.

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 ago
  I'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 ago
    What 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 ago
      www.linux.org/
      - dalore 16y ago
        It is GNU/Linux thank you.
        krakensden 16y ago
        Distributions are GNU/Linux. The Linux kernel is Linux. And yes, I did well actually you.
      - kijinbear 16y ago
        They don't all work on the same part of the kernel.
        bad_user 16y ago
        Sorry, 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 ago
      Your 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.
  - numeromancer 16y ago
    Throwing bodies at a problem can help, though. [Piling] bodies at [the door] can help, though. FTFY.
  - gridspy 16y ago
    I'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"

by greyman 16y ago

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 ago
I'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 ago
  What 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 ago
    www.linux.org/
    - dalore 16y ago
      It is GNU/Linux thank you.
      - krakensden 16y ago
        Distributions are GNU/Linux. The Linux kernel is Linux. And yes, I did well actually you.
    - kijinbear 16y ago
      They don't all work on the same part of the kernel.
      - bad_user 16y ago
        Sorry, 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 ago
    Your 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.
- numeromancer 16y ago
  Throwing bodies at a problem can help, though. [Piling] bodies at [the door] can help, though. FTFY.
- gridspy 16y ago
  I'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"