Best way to Structuring Large Development Teams

Question

I have a client that recently laid off 40 developers who worked a single java project for 3 years without being able to produce a workable piece of software. I recently had a thought, rather than having all 40 developers work together on the same project and create all sorts of bugs, would it be better to create small competing teams?

So the layout would be you have a single project that needs to be done. And you have break the development group into 10 teams of 4. Each week you check the progress of each team and you eliminate a team that isn't performing. By the end of a few months you narrow it down to the top 3 and pick the solution that is the least buggiest to release with. Thoughts?

UPDATE: I have advocated paying 4 developers 250k a year and grab all the top talent out there but companies refuse to do it. You can't convince managers that one programmer is 10x better than joe programmer. The reality being joe programmer will probably cause a lot of harm to the project ala spegetti code and horrible programming worthy of thedailywtf.com. I'm not saying fire the losing teams, just put them on bug fixing projects, or maintenance. The competition is to create the new code base.

Answer 1

Why not just hire four competent programmers?

Answer 2

I would not like to lose a good programer ( putting his/her to some bugfixing ) just because some other guys from his team are bad.

Answer 3

Why waste time/effort/cash/energy on dealing with multiple competing teams? Interview and hire programmers that can do the job and simplify life for yourself.

Just my two cents.

Answer 4

My take on this is that you believe the low productivity issue is primarily motivational. You wish to harness competitive instincts to overcome the lack of motivation.

First of all, what analysis have you done to arrive at this conclusion? There could be a lot of different reasons why productivity was so low. Get the analysis wrong and the problem won't get fixed.

Assuming that you are correct, you could use Cogenuity to orchestrate and structure the competition. Cogenuity is a challenge based collaborative platform where contenders compete for the best solution to a challenge and the promoter reviews the panel of experts opinions as to the merit of the individual solutions and awards the purse to the winning solution.

Answer 5

As itsmatt mentioned, competition is a waste of resources.

In this case you have 40 developers of varying skill levels, some of which are probably not very good, and some of which are probably very good. If you separate them into smaller teams with discrete and observable deadlines, you will be able to better measure which teams are falling behind.

40 people working on a single codebase is bound to be an unorganized disaster, but four people working on a single component has a much greater chance of producing something. If you take 40 people and have them compete in four man teams, you'll find that the end output will be better than a general four man team, but not on the order of 10x which means that you will have lost time.

Also, your good employees would quit once they found that they have NO job security. Because if they are on a weak team, they all get fired. It would cause incredible tension, and a huge resentment against management for toying with them this way.

I read in 'Guerilla Programming' (I believe) that it is a good way to get teams motivated by running one of these competitions over a weekend (48 hours, no sleep). It builds moral because it is turned into a game, and they're fighting for pride. But no one is getting fired. They don't believe that their livlihood is depending on it.

Ultimately, this is a BAD idea.

Answer 6

It sounds to me like you have the makings of the world's worst rated reality show.

Answer 7

rather than having all 40 developers work together on the same project and create all sorts of bugs, would it be better to create small competing teams?

(Emphasis added.)

So you think that on the same project, from start to finish, a small team will produce fewer bugs than a large team? It sounds, then, like you think the bugs in the previous codebase are there because of poor communication among team members.

IME that means the project had the wrong mix of people. On a team of 40, there should be a few people (maybe up to 5) who divide the project into pieces manageable by a smaller team (<10). These people should also define the interfaces between the teams, personally lead one of the teams, and as a group deal with any project-wide issues (like i18n, etc.).

If those folks don't do their job well, you end up with a project like your client's. Or worse.

The answer isn't hire another 40 people randomly, put them in a steel cage and see who emerges victorious. Instead, hire 5 good people, let them hire 35 decent ones, and give the 5 good ones the tools they need to get their job done.

Answer 8

You may find this article on Gamasutra interesting, which talks about Valve's "Cabal" design process. It sounds similar to your small competing teams idea, although it doesn't include elimination of "the weakest link".

We would create our own ideal by combining the strengths of a cross section of the company, putting them together in a group we called the "Cabal."

Answer 9

Brooks came up with the answer in 1975: like a surgical team.

But the question, as updated, is not "best way to structure a large development team", but "least bad way to structure a large development team that clueless mgmt will approve". That's really a social question that only you can answer, knowing the particular brand of cluelessness that your mgmt is infected with.

Answer 10

Nothing wrong with having 40 developers on one codebase. What you need is two things:

• Good lead programmers
• Good managers.

I'm guessing your project didn't have one of those two things, most likely the managers.

Answer 11

Yeah, I agree with Ken. Read Brooks's book called Mythical Man Month.

Answer 12

By the end of a few months you narrow it down to the top 3 and pick the solution that is the least buggiest to release with. Thoughts?

This doesn't address the question of how much functionality have the various teams done completely and partially. Is it better to have a solution with extremely limited functionality that is bulletproof,e.g. you can log-in and out and change password and that's it, or to have a half-baked solution with 100x more functionality but with a few defects in really weird user error cases, such as a user tries to debit a negative amount of money or other things that just often don't happen that programmers didn't have time to write the code to handle?

Answer 13

I think this is a great argument for outsourcing development teams. Because when a firm can develop similar software programs for several clients, they can see what works and what doesn't from project to project. Thus your four or more competing code bases.

The dark truth of any form of creativity is that the first few drafts never really work, it's only the third of fourth or after where things really begin to take off. Good writing is rewriting as the phrase goes.

It sounds to me like, in addition to the obvious managerial issues, the real disaster was that a single huge project was too daunting of a focus for the team.

Answer 14

Competition within an organization is generally a bad thing. And when you're competing for your own job, it's got the potential to turn nasty. Suppose team x has a problem that someone from team y knows how to fix. Is competition going to be an incentive for them to help out or to sabotage the other team.

I have advocated paying 4 developers 250k a year and grab all the top talent out there but companies refuse to do it.

All I will say is that it takes more than lots of money to lure good programmers.