Saturday, June 06, 2009

Time to end Foie Gras recruitment

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.


  1. That reminds me of the early days of JavaSoft. They were recruiting so fast that, literally, noone could have known what they were doing.

  2. Your observations are entirely true in practice. However, there are many factors that affect this, and influence the severity of the problem as well as a teams ability to deal with the problem. You mention one, the teams processes and practices. However, another really important one is the character of the developers involved, especially the new ones.

    Imagine the hypothetical case where you magically recruit only developers that are actually capable of such a high level of self training that the negative impact on the team is much less than average (obviously never zero). Imagine also that the answers to the questions are usually available without another team member having to spend time (ie. in the code itself, and associated well written documentation, including feature specification, project goals, etc.).

    Can this be done in a real corporate project? I believe so, and I believe I have just done it. Read my blog on the subject at

  3. Allan,

    I agree completely with what you're saying. The current project i am on just pushed back against recruiting any more developers to it. We're on a tight schedule and every works together very smoothly.

    However, there are ways to structure hires to mitigate. The primary method is to use Fred Brooks' idea of a surgical team. So a new developer will take the burden of writing tools for development and test. Also, it's possible with some functionality in an application to make it a separate application to begin with. This can lessen the impact of a new developer. Although you still have to be very careful and disciplined in your approach.


Note: only a member of this blog may post a comment.