Dictated because of a slightly dodgy keyboard into Arcturus
[I’m giving up on trying to get Librarians motivated about DRM. They clearly accept it in a supine manner as being “the law” (it isn’t). They aren’t interested enough in the harm it causes their reader community. Here’s something more exciting – and if I mention DRM to this community you bet I would get a reaction.]
One of the strengths of JISC and a very positive reason for working with them is a the strength of their programme management. (I always confuse programme and project management and if I get it wrong here please correct me). If you are interested in bidding for a JISC grant then liaising with the programme manager is extremely useful to both sides (the simple secret is that JISC wants your project to succeed! They are friends not enemies). The programme managers call Town meetings to discuss bids before the event and workshops after it. I have two JISC workshop meetings next week for example. It seems very OTT in management, but it’s a good investment.
Dave Flanders is one of the programme managers at JISC and we were chatting in the bar at Dev8D (I haven’t even blogged about that wonderful event). The topic turned to the productivity of programmers (i.e. those who write programs (not programmes)) – often called developers (Dilbert calls them engineers). We recognise that there is a huge difference between the mediocre 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 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.
And some comments
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.
Ross Gardler said this on March 25, 2010 at 3:09 pm | Reply
-
[DaveF] 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).
dfflanders said this on March 26, 2010 at 10:33 am | Reply
PMR: I am prepared to defend these order of magnitude differences (though the exact scale is questionable). There are of course many tasks which bring every one down to the same level. For example if a developer has to create a periodic table of the elements and type the data in (to avoid copyright problems) then a guru will not do it quicker and may in fact do it worse. What I am talking about is the ability to create a great piece of working, a reusable, distributable piece of software. In many cases getting a project 90% correct is equivalent to getting it zero per cent correct. So the ability to create the correct design is as important as the ability to understand arcane pieces of code. Indeed is the code is arcane then it is almost certainly poorly written or depends on a poorly created library.
Dave praises Jim Downing and rightly so. Jim is one of the great developers that I have known. In the time that he has been with us (somewhere between three and five years depending on how you count) he has given us some truly revolutionary designs for our software. His system Lensfield will be a milestone in Scientific Software. It’s truly revolutionary it so it will take some time to understand, but I have used its principles over the last three weeks to do things that I could not possibly do otherwise. This is why I think that a factor of one hundred is not impossible.
Jim is not a top guru. Jim listens to the top gurus, like Jeff Attwood and Joel Spolsky. Kent Beck created one of the truly great tools for developers, JUnit tests. The code itself is easy to write. However the impact of this small amount of code has been sensational. So I would put Kent Beck somewhere in the stratosphere, adding at least one more orders of magnitude given the influence that his work has had on the community. So where does Jim come on this diagram? Probably about 8.5. Where do I come? Perhaps around 6.5. This includes the fact that I have many years of experience of what not to do, and that I have had the opportunity and a determination to set up a group where Jim has been able to develop and impart his skills.
Originally I proposed a logarithmic graph but this does not account for the fact that some developers have a negative influence. We’ve had experience of this. Obviously no names, but one developer (nickname suggested by a red dwarf episode) when confronted with a failing unit test would change the test so that it “passed” – the version control system that we were forced to use did not record that there had been changes.
Want to Jim has shown us is that it is possible for people to move up the curve. This is by introducing and using modern methods of software development, which are relatively uncommon in scientific programming. This is an area or we have debated with JISC programme managers; how can we jointly work towards a better standard of programming in the scientific arena so that individual projects do not simply die. In future blog post I shall show some of our tools and some of the results, which are a tribute to Jim’s vision and methodical commitment to delivery.
We shall miss him very much indeed.