Good, Great and Guru Developers – An Algorithmic Skill Scale

It was Peter Murray-Rust (PMR) who proposed this scale to me at dev8D which helped refine a straw man diagram I’d been working on for a while since a chat with Jim Downing at OR09 on scales for learning curves on picking up programmatic concepts.   The vertical access is the percentage of work that can be completed by a single developer on a system/project; the horizontal access is a one to ten rating scale for developer ability (by “ability” I mean a full spectrum of coding skills as well as user, culture and business knowledge by which the software is contextuliased within); I ‘d welcome comments/refinements.

The significance between having goodDev, greatDev and guruDev is the observable fact that greatDev and guruDev can achieve significantly more than goodDev.  I’d argue that a single guruDev is significantly more productive than having a dozen goodDev.

None the less good software teams (like PMR’s as lead by Jim Downing) manage to balance all three types of developers. Aside:  I’m hoping to attend one of Jim’s Friday code reviews soon (my colleague Andy was recently in attendance and was very impressed, especially with their team motivational use of Hudson).  None the less, there is a significant risk in taking on goodDev who potentially have a negative effect on the production of the team (not that they won’t advance their skills to become productive).

The point of this post being, that developers are not just developers.  One is not the same as the other.  Projects looking to use developers on their team need to understand how significant the selection of a developer is.  Unfortunatly, I don’t think we have a good system for even interviewing developers let alone a way to acknowledge their skills.

More on this later.  Lots of thoughts abound.

Advertisements

~ by dfflanders on March 14, 2010.

8 Responses to “Good, Great and Guru Developers – An Algorithmic Skill Scale”

  1. […] Good, Great and Guru Developers – An Algorithmic Skill Scale … […]

  2. Good points. One of the things that’s started to interest me lately is how people can be good developers in very different ways and be good at very different kinds of development. This is really important when it comes to recruitment because it is very easy to fall into the trap when you are interviewing of trying to recruit clones of yourself.

    I know that there is lots of evidence that there are order of magnitude difference when it comes to programmers under certain metrics. However, I think it’s important however not to send the message that you either have talent or don’t. Likewise, things can be more multi-dimensional in terms of whether you are being of value or not. I say that as somebody who would probably come out quite well according to such metrics, but has learned to appreciate certain types of developer who wouldn’t!

    • I’m with you Juliette, that was part of my reason for trying to stay positive that goodDev are important for projects as well as they might not be productive they are still capable of learning and making a contribution, which later on will result in them being a greatDev. One of the things I love about developers is that the vast majority of them love to learn new things, which makes progressing up the scale a never ending battle that we all enjoy 🙂

  3. I’m not a believer in the Guru Dev as a silver bullet, that is I don’t agree with your assertion that “a single guruDev is significantly more productive than having a dozen goodDevs”, at least not when we think about sustainable software.

    It is true that a guru who knows her stuff can produce more code in less time, but that doesn’t mean anyone else can understand that code or how it was created.

    For me a real guru developer is actually someone who can recognise the strengths of the good and the great and provide an environment in which they can deliver. The combined production of those developers will far outstrip what a single guru can produce. Furthermore, the skills of the majority will have increased (thanks to the guru’s leadership_ and the knowledge of the software will have been spread across more bases.

    • Agreed a dozen developers for one developers is a bit extreme though personally I’d rather have one Ben O’Steen or Jim Downing than a dozen fresh out of CS undergrads on my project <- though agreed that the more minds on a problem the better (there is a separate discussion around all software projects having sustainability as their output, as opposed to visionary or instruction, but we can save that for the pub).

      Also my point is more towards the fact that we don't have systems by which to recognise the good, great and guru (and I'm including the ability to write sustainable code as one of the skills that a great and guru developer should have). Also the blatant problem that Universities do not have any recognised tiered position for developers to progress up the salary scale. We need to make a case towards having junior, senior and CTOs within Universities and that will require metrics of some kind (mythical man month or not).

  4. […] and the top ones. I proposed a scale and Dave has written it up. I’ll comment at the end. Good, Great and Guru Developers – An Algorithmic Skill Scale It was Peter Murray-Rust (PMR) who proposed this scale to me at dev8D which helped refine a straw […]

  5. […] It was Peter Murray-Rust (PMR) who proposed this scale to me at dev8D which helped refine a straw man diagram I'd been working on for a while since a chat with Jim Downing at OR09 on scales for learning curves on picking up programmatic concepts.   The vertical access is the percentage of work that can be completed by a single developer on a system/project; the horizontal access is a one to ten rating scale for developer ability (by "ability" I m … Read More […]

  6. I’m old enough to have been around for the studies that first uncovered this pattern in the early 80s. I read Boehm, Mill, DeMarco, &c and heard them speak at conferences. Since then, all my work running software development groups has shown the pattern to be broadly true.

    Good summary with references here:
    http://blogs.construx.com/blogs/stevemcc/archive/2008/03/27/productivity-variations-among-software-developers-and-teams-the-origin-of-quot-10x-quot.aspx

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: