Back at Feefo I saw the number of developers grow from me to about six before I left. I never gave much thought to team sizes or how to hire. Being caught up with day to day things while trying to implement important strategic changes to the software I suppose my overly simple attitude was that more hands on the pump was a good thing as long as they were competent.
Having had time to reflect and read as well as seeing how things work at companies I’ve consulted for I’ve developed much clearer opinions on the matter. I don’t think my position is particularly advanced but I’ve not heard the principles discussed much before. Some reading (notably Peopleware and The Mythical Man-Month) has introduced me to ideas backed up by my experience and instinct :
1. Programmer productivity varies massively, a great well motivated programmer can be 10 times more productive than a mediocre unmotivated one.
2. Team size causes an overhead in per-programmer productivity on top of this. The effect is not that great up to five people but above that it kicks in heavily, to say per-programmer productivity could be cut in half by this seems conservative. http://www.qsm.com/risk_02.html
Given this I make the following statement :
A team of four or five great happy programmers can be far more productive than a team of 20+ average programmers.
This would not be an outlier either – if compounded by large team overhead one programmer could be more than 20 times more productive than another, all that’s needed for my statement is five times more productive. It could easily happen among a typical range of competence.
So, what follows?
Firstly we should try very hard to limit development team sizes to no more than five even going as far as changing the software’s spec if it’s possible. Management should be aware that tipping over this point means overhead one way or another. Separate teams will probably be required, more process, more project managers etc.
Secondly, since we have limited spaces and we know how much productivity can vary we should hire very carefully and think about how to attract the best candidates. Paying well above the odds should be considered if not endorsed. Interviews can only do so much so probation periods need to be used seriously though this is not always pleasant.
Ideally offer gobs of cash to someone you’ve worked with previously and know is good.
If I’m right then why isn’t this more commonly practised? I’m guessing that “more bodies is not better” might be counter-intuitive to non-technical managers. I’m not sure what they see programmers as being similar to but the team size scaling which might happen in other professions is cut short in programming. Should Azquo expand as we’d like I’ll be gunning for quality over quantity.
My sales pitch might be something like :
1. Decent pay.
2. You’re unlikely to be the smartest person in the room.
3. Napping is allowed.
When the time comes form an orderly queue.