How many developers does it take to complete a project?
-
Any big team is going to be slowed down by having to coordinate almost everything. I think on small teams there can be improved productivity if they team members are highly skilled is specific areas, and their skills complement each other. I have definitely seen productivity go down on a lot because of other developers. I worked with a developer that had a tendency to much with my WPF code without telling me, and he was not a front end developer. Was working with Seapine Software's SCS, and it is pretty bad. He insisted on working directly under the integration branch while everyone else was working in the same feature branch. I managed to overwrite his changes and he insisted I back out. That does not work too well with Seapine since it does not handle deleted or added files well. I lost like 5 days, and his changes were minor in the project I was working in. This was the primary branch I was working. Did not have this problem with any of the other developers.
-
Actually these days developers scale reasonably* well - once we've got the common architecture, tools and source control issues worked out. Unfortunately the ambition of the project owner seems to scale exponentially - i.e. everyone seems to think "It should be like Excel but with these 18 additional functions" is somehow sensible. (* Say 0.3N?)
-
haha agree :laugh: My Associate manager at Accenture alway told me that
-
haha agree :laugh: My Associate manager at Accenture alway told me that
To be fair, I believe credit is due to Fred Brooks: Brooks’ law - Wikipedia[^]
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
I think every project has an optimal size. A big team has a lot of man power, but coordination, interfaces and "ramp up" time is getting bigger and bigger. Often occurs the problem one specialist is waiting on other results. (I am often waiting on our fancy design team) The "smallest team" is one person: Knows all about the project but can only do one job at a time. The optimal size comes from how much work can get done in paralell. :cool:
Press F1 for help or google it. Greetings from Germany
-
To be fair, I believe credit is due to Fred Brooks: Brooks’ law - Wikipedia[^]
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
thank you, for point it out
-
Three to five. Almost any large project can be broken down to discrete projects of 3-5 engineers. (When you add in testers, documentation and perhaps a build-engineer and manager you get about 8-10 people, which is about the size of a military squad/section.)