Developers Are Not Interchangeable

Aptitude, skills and experience all make a difference.

This is one reason why, as Fred Brooks pointed out long ago in the “Mythical Man-Month,” estimates for software development can be entirely misleading.

Software developers are all different, and different along many different dimensions. Here are some of the ways in which they differ:

  • Aptitude – Some developers are simply more capable than others. Productivity differences of an order of magnitude have been documented on multiple occasions.

  • General Experience – Some developers have had deeper and broader software development experiences than others. (This often correlates to years in the field, but not always: we sometimes find that developer A has had 20 years of experience, but developer B has had the same year of experience 20 times.) Successful experiences are also often much more helpful than the other kind, since developers will tend to repeat practices that they have used before, whether they were successful or not.

  • Particular Skills and Experience – Some developers may have background in a certain problem domain, or knowledge of a particular technology.

  • Verbal and Written Communications Skills – Some developers are good at communicating with customers, teammates and/or leaders, while others lack these skills. And some are good at communicating verbally, while others are better at communicating using the written word.

  • Productivity – Some developers seem to get things done, no matter what challenges they run into, while others seem to be easily sidetracked and tend to lose track of goals and commitments.

  • Teaming – Some developers play well with others, while some tend to operate more independently.

When considering these differences, it’s good to be familiar with the Dreyfus Model of Skill Acquisition, since experts often behave very differently than beginners when it comes to their tolerance/need for rigid rules. For more on this topic, see the Pagan Tuna post, “The Dreyfus Model of Skill Acquisition.” Also see “The Seven Stages of Expertise in Software Engineering,” by Meilir Page-Jones.

It’s also good to consider these differences when forming a team. You generally will want a good mix of skills and experience, and you will want teammates who can work well together.

And, of course, you need to maintain certain minimum requirements for your organization. You need people who are smart, who get things done, who enjoy learning, and who interact constructively with customers, management and teammates. I don’t mean to imply that these sorts of people are hard to find. Most of the people I’ve worked with in my career fit this description on a good day, and almost everyone I’ve known (myself included) fails to meet one or more of these standards on a bad day. And certainly all of us have room for development in these areas, and do indeed develop in positive ways over time.

On the other hand, there are situations where not everyone lives up to these standards consistently, where people are progressing slowly if at all, and where you can’t afford to wait for a long-term turnaround plan. These situations are unfortunate for all involved, but ignoring them doesn’t make them go away.

Talented people are the most important element in any software organization.

Counterintuitively, employees already performing above average have the greatest room for growth. Great managers also know that it is hard work helping a talented person hone his talents. If a manager is preoccupied by the burden of transforming strugglers into survivors by helping them squeak above average, he will have little time left over for the truly difficult work of guiding the good towards the great.

Next: Initiation