author: @sleepyfox date: 13-May-2012
How on earth could a set-top-box app software development team (basically a simple Linux UI app to parse a programme and stream some video?) have 20 people on it, when surely 4 or 5 should be more than enough?' a friend asked.
In answer I told him the story of when I started on an assignment for Hutchinson 3G in their new posh glass building in Maidenhead, working in the new 3G products division in early 2002 producing what were essentially a bunch of web apps. I asked my boss how many people were working on the project: "350" was his reply. My jaw dropped to the floor. "Don't worry," he said with a smile on his face "all the real work is being done by nine guys working in a back room of the pub over the road. This new glass building is just a decoy to confuse Vodafone and Orange!"
How on earth could it possibly take 350 people (DBAs, Product Managers, Product Managers, Architects, BAs, QAs, Developers) to produce a bunch of simple web apps? I simply couldn't get my head around what I had assumed would be perhaps 25-30 people, at most.
This was a pattern that was to repeat itself, and it took me a while to understand why. Back in my early days in the IT industry I assumed that experience and productivity were related by a linear function like: productivity = (experience) times a constant: let's call it 'a', giving us:
p = ax
This implies that if a developer had twice as much experience then he would be twice as productive, more or less. The following diagram shows what I mean:
Yes, even then I understood that there's a difference between 'experience' and 'skill', as 5 years of experience could mean 5 years of constant learning and improvement, or 1 year of learning followed by 4 years of repeating the same thing over and over...
It took a few years more before the true scale of what was going on became apparent, good developers with twice as much experience were not twice as productive, they were perhaps four or more times as productive, the relationship between experience (or perhaps ability) and productivity wasn't linear, it was more like a power law:
p = a^x
This looks more like the following diagram:
As it turns out there has been plenty written about this from Steve McConnell1 - the research that shows great programmers are 20-25 times better than mediocre ones - to Mark Zuckerberg's2 famous quote that “Someone who is exceptional in their role is not just a little better than someone who is pretty good, they are 100 times better”. So this isn't exactly new news. People debate this in the IT industry back and forth all the time, but I've noticed that the people who are great developers, or who are managers or executives who have worked with great developers simply take it as empirical fact, and it only ever gets debated by people who haven't actually experienced the phenomenon, or who have actually read the research. It did however take a few more years for the real penny to drop, and that is that for the graph I had drawn in my head, the function does not pass through the origin, and instead of p = a^x the function is more like:
p = a^x - b
The end result of this is that the poor developers who are swimming in the shallow end of the gene pool are not just poorly performing, they are net-negative producers! What does this mean? This means that the programmers to the left side of the graph are the ones producing the bugs that the people in the middle portion of the graph are fixing, they are the ones inserting misleading comments, writing spaghetti code and implementing poor design that the developers further to the right are wasting time fixing, deleting, refactoring and redesigning. If your organisation doesn't have many people in the far right hand side of the graph, then it is easy to see that no matter how many developers you have, you might not be making any forward progress at all, although you will be burning a ton of cash! I've illustrated this with some shading below:
Thus you need more people to the right of the blue section in order to outweigh the net-negatives. If you don't have many people on the right-hand side of where we cross the x-axis, then the reason for the lack of progress becomes obvious. It is this graph that explains the original question: how can you have so many developers and yet be accomplishing so little? The inflection point on the graph of where productivity crosses the X-axis - where a programmer becomes a net positive producer - I now refer to as the:
MVP - Minimum Viable Programmer
As yet another example of how pretty much every idea I've ever had has already been thought up by somebody cleverer, I found an example of prior art on Ward Cunningham's wiki referencing work by G. Gordon Schulmeyer3 - in his own words:
"We've known since the early sixties, but have never come to grips with the implications that there are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one." -- G. Gordon Schulmeyer
This. This is why in 2011 a major household name came to the company I was working for and asked us why with more than 120 off-shore Java developers on a project, they couldn't make any progress. Answer: as harsh as it may sound; employ professionals that can actually do the job. As the famous oil-well fire-fighter said when a potential customer blanched upon being told how expensive his rates were:
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." -- Red Adair
Footnotes
-
"Productivity Variations Among Software Developers and Teams: The Origin of 10x", Steve McConnell, 2008 ↩
-
Mark Zuckerburg, quoted in the New York Times, 2010 ↩
-
"The Net Negative Producing Programmer", G Gordon Schulmeyer, 2001 ↩