My Tweets

  • in Austin, TX for the weekend visiting my in-laws...gotta do some tech support for my FIL as well.
  • @CalebJenkins: I think Trudy's in Austin skews that statistic big time...
  • @dpenton: agreed there's always value as it forces SRP and SoC. Dependencies always get abstracted out when unit testing is enforced too.
  • @dpenton: unit testing has value when reqs come from biz analysts. If devs/former devs are involved, reqs get more attention/thought.
  • @jbogard: Common scenario I've seen is when properties have an Enum that does a straight type mapping to the DB. Not a flexible design.

Xbox Gamer Tag

Building a Balanced Team

Thursday, August 09 2007 4 Comments

Fred George, noted Agile Developer and thought leader, had a great post where he described his ideal ratios of developer skill levels when building an Agile development team.

One of the foundations of his theory is that the number of Apprentice or Junior level developers should remain small on any given team.

...bring on apprentices only at the rate they can be productive to the team; otherwise, be courageous and defer the staffing, ignoring what your spreadsheets are telling you.

I can certainly identify with Fred's warnings here as I've had the unfortunate experience of working in a shop which built upside down teams with one skilled senior developer managing 5-7 fresh college graduates underneath them.  The net effect was a very buggy system, poor productivity, and continuous death marches between releases.

As many others have said before, programming is a skilled craft, and thus must be treated as one.  While it's true that almost anyone can learn to hack together some working code, true mastery of the craft requires learning under existing masters.  And for a master, training even one apprentice requires a significant time investment that can often come at the cost of productivity.

In my current role at Telligent, I've had the good fortune of working with a very talented Junior Developer and I've enjoyed helping him go from being a good programmer to being a great developer.  However, it's been quite clear to me that having more Juniors on my team would quickly overwhelm me and begin to adversely affect my team's productivity. I would probably be spending more time on mentoring them and less time on knocking things out of my own task list.

Even the brightest Juniors will not be aware of all the tools, resources, and practices that are at their disposal as compared to a more experienced developer.  In summary, Fred George said it best:

...start your projects with few, if any, Apprentices, and stage them into the project at the rate you can productively absorb them.

I highly advise that you read the rest of Fred George's posts in his series on Masters, Journeymen, and Apprentices.

Comments

#1 On August 10,2007 at 7:10 AM David O'Hara said:

I just finished up reading his posts yesterday - a very thoughtful series and certainly one that I'd recommend to anyone in an upper level position. Like you, I've found these ideas to not only be true but, sadly, the exception rather than the rule.

#2 On August 10,2007 at 7:09 PM Karthik Hariharan said:

I've noticed the upside down team used to be very prevalent in larger companies that relied on new hires for the majority of their work force.

Even today it is still prevalent, but it often comes in the form of offshoring/outsourcing with similarly built teams halfway across the world.  The addition of both the physical distance and time difference often amplifies the problems associated with too many inexperienced team members.

#3 On August 14,2007 at 10:05 AM Ash Bhoopathy said:

"I've noticed the upside down team used to be very prevalent in larger companies that relied on new hires for the majority of their work force."

I don't know what you could be talking about, Kar :)

Hey, I just noticed your favicon.  Did you always have that little guy?  It's cool.

#4 On August 15,2007 at 11:14 PM Karthik Hariharan said:

Ash,

yes you know exactly what I'm talking about...the company who must not be named ;)

Favicon?  Whats that?