December 4, 2005

...Learn TDD with Codemanship

It's The People, Stupid!

One question that comes up almost inevitably with clients is "how do we build a development team?" Anyone that knows me knows that I have very strong views on hiring (and firing) software professionals. The word that makes my blood boil is resource - in all it's various forms; "resourcing", "human resources", "resource pool", and so on.

There's a pernicious myth going around that one developer is pretty much the same as another. Managers are very attracted to the idea that they can can easily replace one Java guy with another Java guy, like changing a light bulb or putting a new filter in the coffee machine. The reason this is so attractive is because it makes developers expendable - and when you're expendable, that puts a significant weight on the client or employer's end of the relationship. They call all the shots.

Recruitment consultants also benefit from this mythology. If one developer is pretty much interchangeable with another, then there are no limits to the size of the teams you can staff, at considerable profit to yourself.

Between them, managers and recruiters (and HR folk) have created a commodity market for something that cannot be commoditised. The upshot is that pretty much any kind of developer can end up on any kind of project, and for some reason the best developers get paid roughly the same as the worst developers, because - in the eyes of the people paying - there's no real difference.

This is nonsense, of course. There's a massive difference between the output of the best and the worst developers - literally orders of magnitude. To illustrate the silliness of it all, I conducted an experiment late last year with an old client. I described a query language interpreter that had been built to a very high standard in 3 weeks by one very talented programmer who you may have heard of. I think he charged about 15k to do it. I told my old client that it was completed in 10 weeks by a team of 4 developers and that it cost 80,000. I asked him if he thought that was reasonable. He seemed to believe it was. So then I told him I'd lied, and that it was actually developed by one guy in 3 weeks for 15 grand. He thought that was a bargain, compared to what it could have cost. I then asked him which he would hire for his project - the talented developer charging 1,000 a day who is more than three times as productive, or 4 average developers charging 400 a day who would achieve about 3 times as little. Would you believe it? He would hire the average developers, even if he knew it was a false economy. Why? Because it's a decision that he's allowed to make. Hiring 400-a-day developers is easy for him. Justifying a 1000-a-day developer, no matter how productive he is, is just not possible in his organisation.

And this is where the problems start...

I want to champion a change in the mythology, to accomodate the reality. I want us to insist on using different terminology, and to set different expectations. I want managers to know beyond any doubt that the success of their project rests on the quality of the people they hire.

So here's what I propose:


    * From now on, I will refer to "resources" as talent. Whenever a manager says "we need 5 Java developers on this project", I will respond with "you mean, you need some Java talent on this project?" "Resources" are what we fill kettles with or stock up on for the Christmas holidays. People are only "resources" when they are used as draft excluders or lawn furniture.
    * From now on I will refer to "resourcing" as casting. You are trying to find the people who will boost your project's chances of success, just as a film director is looking for lead actors who will boost the chances of a successful production. Can you imagine Steven Spielberg picking up the phone to his casting director and saying "I need three white guys, a black guy and a lesbian"? No, he puts a little more thought into it than that, I'm sure! In cinema, people understand the critical role that getting the right talent plays. If you can't get the people, then your project isn't going to get a green light, let alone a good opening at the box office.
    * From now on I will insist that having the right talent is a prerequisite to a project getting a green light. Who are these idiots who commit millions (or billions) of pounds to projects without a second thought as to who will actually be doing the work?
    * Developers should have a portfolio, not a CV. What have you built? How good was it? How long did it take and how much did it cost? If I'm Steven Spielberg, and Tom Hanks comes along and says "I worked on Castaway", the first thing I'm going to do is rent a copy of the DVD.
    * Managers should value talent first, and then budget for it. 10 million is a lot of money for any old actor, but if you're Tom Hanks, and your last 5 films took an average of 300 million at the box office, then all of a sudden 10 million sounds like a solid investment.


Maybe one day, developers who are ten times as productive will get paid ten times as much, and will be able to choose the projects they take on more discerningly. Until that day, I will stick to my new pledge and try to change a few minds about how you build winning teams.


Posted 15 years, 1 month ago on December 4, 2005