Big teams and “superior leads”
I started writing a response to the Sven’s comment on the previous post and the comment got too big so I’ll post this as a separate post.
The problems of a big team can’t be solved with with “superior leads”. Those large teams need to make their important irreversible decisions in the beginning of the project, before starting work on the larger scale. Smaller teams can make decisions on the same things but their point of reversibility is being pushed further in time. Small teams can re-design and carry out ground-braking changes throughout the code-base without halting the whole team.
Having the need to make the decisions upfront leads to the well documented big-design-upfront antipattern. This means that there will be no information about the emerging important details and the context to support the decisions, there is no good way to respond to changing requirements throughout the project later on and the initial naive view on the problem domain will make the domain model too awkward to work with. And there are probably more problems to follow. Although having experienced “superior leads” “in charge” will lower the risk of making terrible up-front decisions, those leads still can’t see all the problems in advance. Especially if the project itself is large and complicated and requires a lot of manpower to complete.
This leads to one thing – the most effective way to finish a large project is to hire or compile a small number of smart and productive programmers for the team(s), who can make the right decisions (and re-decisions) at the right time. Splitting a project into smaller sub-projects (so that each team could work on their own subcomponent) might help, but this will introduce another extremely irreversible decision of choosing a wise system decomposition. And that, of course, is another long story 
Comments
One Response to “Big teams and “superior leads””
Leave a Reply
Getting more capable (read: effective) people is always more effective, no doubt about that
But as to components – it is still much easier to implement system wide change in a system built of components even then it means shoveling around some components, merging them or breaking apart. Changes forcing you to change component structure are also much less probable than changes touching single component. Especially if you start small and not completely naive with small-design-upfront to get your component structure somewhat stable.