3 ms·

> I strongly suggest this kind of risk to be dealt with at the human resources department. Assuming that the only problem is that they are inexperienced... On

by itgoon 17y ago

> I strongly suggest this kind of risk to be dealt with at the human resources department. Assuming that the only problem is that they are inexperienced... On a team of that size, you're not only doing development, you are (or should be) grooming future senior devs. In the enterprise world, on timelines that run 5-10 years, with groups 100+ in number, you have an entire ecosystem to manage. Also, in groups of that size, you're going to make mistakes in hiring. I've seen the same thing on small teams, where the whole team interviews someone who ends up sucking. With a 95% success rate, with 100 people, you're still talking five screwups. Breaking things into smaller teams doesn't necessarily get you what you want, either. You end up with a bunch more management, turf wars, and a bunch of other hard-to-deal with crap. Basically, at the really large scale, it is less about the code, and a lot more about managing people over a long timeline.

rbanffy 17y ago
One of the key arguments in this thread is that, perhaps, you won't need 100+ developers unless the technology you are using requires 100+ developers to meet your deadlines. I have been using non-C++-ish languages for about two-and-half decades now and I never met a BFEA that demanded such a huge team. In fact, I regard huge projects like this as very risky and always advise smaller projects that can bring more to the bottom line and that can be implemented in steps. What the hell are you doing that needs such a huge team?
- itgoon 17y ago
  Why would they all be working on the same thing? If you've got 20K+ employees, 100+ developers isn't all that many. Hundreds of departments across dozens of businesses leads to a few dozen projects going on at once. Add in the maintenance of apps that are often 5-10 years old taking up a large chunk of those resources, and 100 developers isn't really all that many. BFEA-wise, the technical challenges revolve around the intersections between the various projects - message queues, batch servers, databases, storage (and more storage). Proponents of independent teams tend to dismiss these challenges, resulting in an overall environment that is more expensive to implement and manage. (for example, sure, that obscure OSS project may be _perfect_ for the task, until the one guy that knows it leaves, and you have to pay someone top-dollar to ramp up on it) To be fair, there's usually a lot of room for improvement, efficiency-wise. To continue to be fair, I don't know that the success rate of small dev shops is any better or worse than the large: there are more failures than successes, and many more "good enough" situations.

by itgoon 17y ago

rbanffy 17y ago

One of the key arguments in this thread is that, perhaps, you won't need 100+ developers unless the technology you are using requires 100+ developers to meet your deadlines. I have been using non-C++-ish languages for about two-and-half decades now and I never met a BFEA that demanded such a huge team. In fact, I regard huge projects like this as very risky and always advise smaller projects that can bring more to the bottom line and that can be implemented in steps. What the hell are you doing that needs such a huge team?

itgoon 17y ago
Why would they all be working on the same thing? If you've got 20K+ employees, 100+ developers isn't all that many. Hundreds of departments across dozens of businesses leads to a few dozen projects going on at once. Add in the maintenance of apps that are often 5-10 years old taking up a large chunk of those resources, and 100 developers isn't really all that many. BFEA-wise, the technical challenges revolve around the intersections between the various projects - message queues, batch servers, databases, storage (and more storage). Proponents of independent teams tend to dismiss these challenges, resulting in an overall environment that is more expensive to implement and manage. (for example, sure, that obscure OSS project may be _perfect_ for the task, until the one guy that knows it leaves, and you have to pay someone top-dollar to ramp up on it) To be fair, there's usually a lot of room for improvement, efficiency-wise. To continue to be fair, I don't know that the success rate of small dev shops is any better or worse than the large: there are more failures than successes, and many more "good enough" situations.