Team Development

I spoke with a friend recently who told me that his company had just hired another programmer to keep up with the work. Good problem. Bad solution.

I asked my friend, "What skills does the new team member bring?"

"He's a very good programmer."

Ah. But he already has a very good programmer. But two is better, right? Well, not always.

I've seen a lot of companies make what I consider to be a mistake: they take their existing model and multiply it. More work? Add another programmer. What's wrong with this? Programs are complex beasts, typically encompassing a user interface, programming logic, persistence mechanisms, etc.

What my friend is subscribing to is the "craftsman" model of programming. One programmer takes responsibility for an entire project (or perhaps the project is split across functional modules -- you do the Store component, I'll do the Customer component, for example).

In every case that I've seen this model tried, it underperforms. Why? Using this model, each developer must be expert at all aspects of web development. And that's just not possible. Instead, it guarantees a certain level of mediocrity: we do a little UI, a little database stuff, some general programming, etc. We do all of them fairly well and none (or, if we're lucky -- one) well.

I find that a much better model is splitting the team along skill lines. If a company is going to have four team members, I'd much prefer to have a UI specialist, a database specialist, a framework specialist, etc. By allowing each team member to delve deeply into a particular area, the overall capabilities of the team are greatly enhanced.

"But I'll get bored!" A common objection. But is it real? Not in my experience. The deeper a developer goes into one area, the more interesting it becomes -- and the greater their utility to the team. Expertise rewards those committed to it.