This question seeks a rule-of-thumb answer so I avoid details. In recruiting a development team to develop and maintain a web application (or windows, whatever); what is a good ratio of alpha-developers (very brilliant developers who are geniuses) to okay developers (experienced-developers whose intelligence will not blow you away) to newbies (junior/inexperience/newly-minted developers)?
views:
174answers:
6
+4
A:
As an overall guide, the idea is this: you want as small a team as possible to get the work done. BIGGER TEAMS DO NOT ACCOMPLISH WORK FASTER. You want the leanest, best, group of individuals possible. 9 women cannot have a baby in 1 month and a horde of mediocre software engineers is not equal to a small number of superior engineers.
Making a lot of sweeping assumptions about the size and nature of the project simply because you didn't include those details in the question (which thereby makes any attempt at answering such as this one almost completely worthless) ...
Ideally: Small and 100% alpha (3 alphas and no one else for a typical "biggish web project" - impossible to quantify better without more details from you) Realistically: 2 alphas (to keep each other honest and so that they can bounce ideas off of one another) and the rest "okay"
In any event, zero newbies is ideal if possible.
Clay Fowler
2009-10-23 20:36:25
Nice answer. I do not mean to read like a picky beggar but I beg to differ that "zero newbie" is ideal. These newbies are the ones who do the burdensome grunt work (mediocre and/or tedious work that needs to be done but too mediocre and/or tedious for highly paid developers.)
Phil
2009-10-23 20:43:41
-1 for wasting money hiring alphas to do monkey work. At best, you merely wasted money. At worst, you got your alphas bored 1/3d way through the project and they quit.
DVK
2009-10-23 20:58:39
Not to mention that somebody needs to give the newbies experience. That may not directly affect you, but it's something to think about.
David Thornley
2009-10-23 21:32:18
@DVK Why are you doing monkey work at all? If you really have monkey work, outsource it. Your competitive advantage is always going to be in the bits and pieces that are hard to duplicate by others, and that's what you need "alpha" programmers for.
Bob Aman
2009-10-23 21:32:31
@David Sure, and that's what school and coops/internships are for. But if you bring those people into your organization, pay them what they're worth (usually nothing) and don't let them side-track you. In my experience, newbies learn fastest when you're not paying them.
Bob Aman
2009-10-23 21:35:10
@DVK What sort of "Monkey Work" do you mean?
Rob Howard
2009-10-25 09:28:18
@Bob: if you don't pay them it means they know nothing and need to learn a lot, that's why they actually learn faster. This learning faster is not a *consequence* of not paying them.
Lo'oris
2010-04-23 11:08:52
+2
A:
Assuming your alpha developers are also good mentors and team players, then the general rule is that one person can only mentor/overlook ten people before they are spending 100% of their time helping and 0% working. So you need one ALPHA for every 10 experienced. Junior developers should exist in ratio with the complexity of your app. Is it 90% trivial stuff that they can cut/paste/edit with 10% of really hard stuff?
Generally I try to keep the junior guys at less than 50% of all other developers. That way there's always someone to look over their shoulder if needed.
Russell Steen
2009-10-23 20:36:46
"10" seems high. I suspect it's closer to 5 unless the people being mentored are quick studies.
Bob Aman
2009-10-23 21:27:51
10 seems to much for me as well for regular overlooking especially if the alphs has his own things to do.
Gergely Orosz
2009-10-24 14:40:14
10 is generally given as the absolute max, and would assume that he did pretty much nothing else. As with any rule of thumb, it has limited use and must be taken in consideration of the project, but it helps to rule things out... Ie: I don't work for teams where the ratio is higher than 1/6 usually (because I don't like my leads to be maxed out)
Russell Steen
2009-10-26 15:48:49
+1
A:
Alpha: 1 per team, Ok ones: 70% (including alpha) newb: 30%. More than one alpha geek might cause unseen problems. More newbies will slow development while 30% (think it like 3 newbies for team of 10) newbies will slowly become ok developers within that group.
Cem Kalyoncu
2009-10-23 20:37:21
"More than one alpha geek might cause unseen problems"? Unseen? I think they're very visible.
S.Lott
2009-10-23 20:45:55
Less than 2 alpha geeks can cause far more problems, and is often the genesis of unmaintainable piles of dung.
William Pursell
2009-10-23 21:36:25
Don't ever try to bring multiple newbies onto a team at the same time. If you need more than one, stagger them by at least 3 weeks.
Bob Aman
2009-10-23 21:37:58
Like constantly arguing about design choices, or which operating system to use.
Cem Kalyoncu
2009-10-23 21:40:55
+3
A:
I think the number of developers really depends on the application being built. So far, I have experienced that teams of about 4-5 developers is best. If you shoot for the number 5, then I would recommend 2 alpha, 2 okay and 1 newbie.
However, newbie programmers can give you amazing ideas and create functionality that you could never dream about. So their value can greatly outweigh their lack of experience. Ideally, I would skip the "okay" programmers and have 3 alpha, 2 newbie if you are going for a new product that needs creativity AND control.
All in all, the productivity of the programmers is generally only as good as the capabilities of the management and allowing the programmers to do what they need/want.
Topher Fangio
2009-10-23 20:37:26
+7
A:
If you really need more than one alpha-programmer get them with different area of expertise, still within the same domain of interest, but everyone reigning over their own personal backyard. No more than 2, I'd say.
If you get newbies, get someone friendly and talkative to introduce them to company policies. It could be an alpha, it could be not. If someone has eved done any helpdesk and didn't set fire to the building while at it, he's your "trainer".
Don't underestimate newbies, some newbie know their thing very well and keeping them down will backfire. Some could even challenge your alpha. Make the "trainer" sort out this kind of stuff. Keep training consistent to policies and miss none of them - they can't figure policies out of thin air.
As a rule of thumb I wouldn't use more than 6 people. 2 alpha, 2 ok and 2 newbies. Having the opportunity, newbies could start pair programming with the ok programmers. (At least to see how they roll and IF they roll at all)
Anyway 5 would be better: 1 alpha, 2 (or 3) ok, 2 (or 1) newbies.
Another interesting configuration would be 1 alpha/trainer with a crowd of newbies. It would surely be fun to watch, and could even work, but it's risky. The alpha could go bossy. The first time one alpha tries this, the team must be checked slightly more frequently.
Worst ever would be 1 alpha, 1 ok, and 3 newbies. The ok would feel "promoted" to an alpha role, the alpha would not recognize that, tensions would rise, newbies would stop caring about those two and roll on their own terms. (with varying mileage)
ZJR
2009-10-23 21:02:14
You're dead-on with what *wouldn't* work at least, but I'd bias more towards "alpha"'s than you have.
Bob Aman
2009-10-23 21:40:09
+2
A:
To me, the sweet spot for a team size is 7 +/- 2. For a team of 5 people, I'd say 1 alpha, 3 or 2 ok and 1 or 2 juniors (depending on the amount of grunt work, but never more juniors than ok). For a team of 9 people, I'd go for 2 alpha, 5 ok and 2 juniors. If you need more people than 9, split the team into 2 teams and spread people accordingly to the first pattern.
Pascal Thivent
2009-10-23 21:17:18