I can never decide if I actually like foie gras as a food. The taste is always secondary to the thought of the force feed ducks. This production process has led to attempts to ban foie gras – as in Chicago a few years ago.
Personally I’d like to end a practice I’ve seen too many times in the software industry and which I’ve come to call foie gras recruitment.
Foie gras recruitment is the forced expansion of a development team beyond the ability of the team to absorb new people. It happens when an organization decides it needs more software produced and decides to do so by hiring lots of new developers.
For example, an internet company I worked with a few years ago. The company faced a rapidly expanding market and needed more from the development team. I was asked help them improve their development processes and practices (“get agile”). When I turned up on day-1 I found four new developers were starting that day and another the following week.
This was on top of the two new developers who had been hired two months previously. And as if that wasn’t enough the company was opening a US development office and had three new recruits starting there the following week.
Given that the original development team was only four strong that is more that is more than a 100% increase. Unfortunately it was too late for me to stop any of this, I just had to pick up the pieces.
This was not the first time I had seen this problem and I’m sure it won’t be the last. The reason why companies do this is because they feel the need to get more done. However the immediate effect of stuffing the development group with new people is to slow everything down. The more you force feed the group the greater the slow down. Hence foie gras recruitment.
Most developers know Brooks Law: “Adding developers to a late project will make it later.” This can be generalised as “Adding developers slows work down.”
This is because new developer need time to learn their way around the system, the tools, the process and practices. When they don’t know they have to ask. People need to tell them things. Those people are the current developers. So they get less done. The more people you hire the slower things go.
(A related problem is hiring just developers rather than a balance of developers, testers and BAs/Product Owners but we’ll leave that for another day.)
In my experience a new developer needs at least three months to become productive. In the book Organization Patterns of Software Development Jim Coplien and Neil Harrison suggest the figure is closer to one year.
I’m sure someone will say: “But if the business want that” or “If we really must deliver more we need more people” but the reality is: more means slower. It is one of those occasions were someone need to explain to “the business” that more isn’t what they think it is.
This gives rise to the latest Kelly’s Law of development: In the short term your development resources are fixed – they may only be reduced.
Of course in the long term you may need to increase your development team and you should hire new developers. The right way to do this a rolling programme of recruitment. Aim to hire, say, one new developer every six months.
The frequency with which you hire will depend on things like: your current team size (big teams can hire more frequently) and the structure, number and interdependency of the existing team(s).
In any company there will be some level of natural loss and you may well want to set you hiring level to allow for this.
In the short term, if you really need to improve your through put then you need to look inside the team at the process and practices and see what can be changed there. Even here it takes time to improve throughput.
So, good bye to foie gras recruitment, hello to a little and often.