Gavin Terrill's Blog

Software Developer Cost Benefit Analysis - Redux

I couple of years ago I blogged about the economics of hiring a few really good developers over a lot of "average" performers, so it was interesting to read Martin Fowler's Cheaper Talent Hypothesis.

Martin identifies the same advantages that I did:

• For any given project, it is cheaper to staff it with a smaller team of more expensive resources than a larger team of middle of the road resources.
• It scales better - you get more productivity per head count, although Martin figures it as not being linear as I did, but more square root n due to greater communication overhead (I'd argue this impacts the larger teams more adversely, so the net effect still ends up being linear). He also choose a "betterness" factor of 2 as opposed to my 3, or Brooks' 5-10.

An additional advantage that Martin points out is that the smaller team, being more productive, can get to market more expediently:

They'll complete the project in half of the time of the average team, which means that the customer will start yielding value from the delivered software earlier. This earlier value, compounded by the time value of money, represents a financial gain for picking the talented team, even thought their cost per output is the same.

The other point Martin makes that I really agree with is code base quality:

Faster cycle time leads to a better external product, but perhaps the greatest contribution a talented team can make is to produce software with greater internal quality. It strikes to me that the productivity difference between a talented programmer and an average programmer is probably less than the productivity difference between a good code-base and an average code-base. Since talented programmer tend to produce good code-bases, this implies that the productivity advantages compound over time due to internal quality too.

There are a few problems to overcome before any of this becomes mainstream:

1. It is hard to find and attract really good performers. There is a very good chance they are already gainfully employed and probably being treated quite well, thank you very much. Unless your name is Google, it is hard to convince people to jump on board with a lesser known and smaller outfit.
2. Telling HR and your CFO that you want to pay your developers more than management can be a hard sell.
3. In an environment with existing teams, how do deal with the inevitable Tall Poppy Syndrome?
4. And finally, how do you assess an individual's productivity at interview time? A big salary expectation does not necessarily correlate with rock star level performance. Martin mentions that peer assessment is used at ThoughtWorks, consistent with what Joel says in his Guerrilla guide to interviewing.

The issues listed above make implementing something like this is very difficult. As a senior manager, you pretty much have to put your career on the line to get past item 2, and you can bet there will be a lot of eyeballs on your "high performance" team, making #3 critical to get right.

The Blissful Interview Candidate

The Caffeinated Coder posted an interesting item today about a psychology study that shows that less competent people are generally over confident about their abilities by around 50%. Giggles about management aside, I've seen this bear out in my experiences.  The study showed that the only way to make incompetent people understand that they didn't know what they were talking about was to educate them about the domain. Only then, did they truly understand how foolish they sounded.

This reminds me of something I look out for when interviewing Java developers. I have made it my business to get down deep and dirty on the nuances of the Singleton. I believe it is important for developers to do some sort of coding during the interview process. Typically I will stub out a class for candidates and ask them to fill in the rest:

public class SingletonTest {
  // ... code goes here ...

   public static void main(String[] args) {
    // Your task, should you choose to accept it, is to make this line of code work
    SingletonTest st = SingletonTest.getInstance();
  }
}

Most folks know the Singleton. If they don't then I will explain it, but will probably not hire them because not knowing the GoF Design Patterns is a candidate smell to me.

After they have filled it in, I will ask questions along the lines of:

1. Why is the constructor private, and not package or protected level access?
2. What are some of the alternative ways of initializing the single instance?
3. Is this class threadsafe?
4. For a static class variable with an initializer (private static SingletonTest instance = new SingletonTest()), when does the object get created?
5. If we make the constructor protected and extend the class with a new class SingletonTestPlusPlus and then call SingletonTestPlusPlus.getInstance(), what is the type of variable st in main - SingletonTest or SingletonTestPlusPlus?
6. Trace the call stack with me at initialization time. Would SingletonTestPlusPlus's constructor be called before or after SingletonTest's?

Most people ace the code, and easily answer #1. I'm amazed how difficult #2 seems to be, but eventually people will figure out there is more than one way to initialize a class variable. By the time we get to #3 and #4 it starts thinning out pretty dramatically. I rarely get to #5 or #6.

The point of this exercise is not for the candidate to get everything right, but to see how they operate when they don't know an answer. My observation is that the more competent you are, the more intelligent a conversation you can have, and that is really what I'm looking for here. I like to see candidates who are on a voyage of discovery, buoyed by a passion for knowledge and personal improvement.

I certainly don't mind push back either - I think that is a good sign. You should not simply accept what anyone is telling you if it goes against everything you know and hold true. At the same time, you need to have an open mind and be willing to learn - that is the sign of a competent person.

One candidate I had called me out on the relevance of the Singleton and said he would write a Service Locator implementation instead. For the record, I think the Singleton is pretty much irrelevant in these days of Dependency Injection, but the candidate could not be convinced to write one in spite of my agreeing with him. That candidate was a "no hire".

Over the years I've had some interesting technical "discussions". No one has thrown a punch at me yet [1], but there has been some interesting and heated debates about the relative merits of lazy initialization over static initializers, or where the curly bracket should be, or double checked locking idioms, or why the main method in Java is so verbose. Reminds me of something my mother is fond of saying: "Ignorance is bliss". But then again, she was a teacher...

[1] I once worked with a project manager who got into a fight with a candidate during an interview and punches were thrown. Perhaps the fact that he was a pompous, self righteous, git had something to do with it.