Sometimes, having a big developer team might mean that they lose focus on certain core aspects.
I used to work at Northrop Grumman IT (NGIT) as a hardware guy in a software company. We had 400 developers at my location. One of my many "other hats" was as 1 of 25 or so alpha and beta testers for our secure networking system used for DoD and State Department secure global communications.
An important fact is while many of the beta testers were developers, no developer beta tested his or her own code.
I don't really want to call it "in-fighting" but I can think of no better term. There was always a lot of in-fighting among the developer teams (and sub-teams) on what should be the best approach. This often resulted in a lack of focus until the big doggies (and client) decided on the course they wanted. It was a big PITA because there were so many people making inputs from so many directions. Too many cooks... .
And speaking of the client, to make matters worse it was not uncommon for the client to force a course change in the middle of the stream too. In some cases, we had to go two directions at once until DoD and State came to a consensus on what they wanted which typically did not happen until the 11th hour before the release deadline - a colossal PITA resulting in many all-nighters in a
SCIF. Not fun at all.
In fact, it was brutal. So were the associated "peer reviews" which we, as the hardware guys, went through too with our hardware. There is just no place for bruised egos or "
pride of authorship". It had to be a team thing with the absolute best course of action in the end product.
But the results were over the 25 years the program was in use, it was extremely rare for any "bug" to make it into the final release. And of the 10s of millions of highly classified messages sent to and from US and allied embassies and military installations around the world, not 1 message was ever lost, misdirected, compromised, corrupted, or otherwise went unaccounted for. End result:
Happy clients. :smile9:
I have also beta tested for small companies with as little as 1 or 2 developers on the "team". It is common in small companies for the developers to beta test their own code. This is like proof reading your own report. Your brain inserts missing words and autocorrects misspellings. Not good. Besides the inevitable in-fighting and ego issues, the results almost always resulted in more problems found during beta testing, and worse, more bugs in the final releases - typically resulting in
unhappy clients.
So having a large development team can be a real PITA, but I think it results in a better, complete and more robust product in the end (once everyone gets on the same page anyway).
