10 Developers For The Price Of One

code 0 comments suggest edit

Update: For an interesting counterpoint to the myth of the 10x engineer, check out this blog post by Shanley. My post is more focused on what makes a good developer than the 10x myth.

In the The Mythical Man-Month, Fred Brooks highlights an eye opening disparity in productivity between good and poor programmers (emphasis mine).

Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erickson, and Grant were measuring performance of a group of experienced programmers. Within just this group the ratios between the best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!

Tortoise and Hare:

Robert Glass cites research that puts this disparity even higher in his book Facts and Fallacies of Software Engineering.

The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field.

In other words, the best developers are generally underpaid and the worst developers overpaid.

But don’t leave your job just yet. This is not to say that there should be a 1 to 1 correlation between productivity and pay. People should be paid by the value they bring and productivity is only part of the value proposition, albeit a big part of it. Even so, we’d expect to see some amount of correlation in pay with such a drastic productivity difference. But in general, we don’t. Why is that?

It’s because most managers don’t believe this productivity disparity despite repeated verification by multiple studies. Why should they let facts get in the way of their beliefs? That would only mean the factonistas have won.

Kidding aside, why is this productivity difference so hard to believe? Allow me to put words in the mouth of a straw-man manager.

Well how in the world can one developer write code 28 times faster than another developer?

This sort of thinking represents a common fallacy when it comes to measuring developer productivity. Productivity is not about the lines of code. A huge steaming pile of code that doesn’t get the job done is not productive. There are many aspects to developer productivity, but they all fall under one main principle (borrowing a term from the finance industry), TCO.

TCO - Total Cost Of Ownership.

In general, I’ve tried to always hire the best developers I can find. But I’ve made mistakes before. Yes, even me.

One situation that comes to mind was with a developer I had hired (under a lot of pressure to staff up I might add) at a former company. I handed off a project to this erstwhile coworker to take over. A few days go by and I don’t hear anything from the guy, so I assume things are humming along nicely.

Fast forward another few days and I swing by to see how it’s going and the developer tells me he doesn’t understand a few requirements and has been spinning his wheels trying to figure it out this whole time.

Good Developers take Ownership so You Don’t Have To

This is one of the first ways that good developers are more productive than average developers. They take ownership of a project. Rather than spend a week spinning wheels because they don’t understand a requirement, a good developer will go and grab the decision maker and squeeze out some clarity.

Likewise, a good developer doesn’t require you to prod them every few moments to make sure they are progressing. If they get overly stuck on a problem, they’ll come to you or their coworkers and resolve the problem.

A developer who can write code fast, but doesn’t take ownership of their projects is not very productive because they end up wasting yourtime.

Good Developers Write Code With Less Bugs

I once worked with a developer who was praised by my boss for being extremely fast at writing code. He sure was fast! He was also fast at introducing bugs into code. His code was sloppy and hard to understand.

The key measure that wasn’t figured into his productivity measurement was the amount of productivity lost by the QA team attempting to reproduce bugs introduced by his code, along with the time spent fixing those bugs by this developer or other developers.

Everyone focused on his time to “completion”, but not on the total cost of ownership of that code. Code is not complete when a developer says it is complete. That is not the time to stop the stopwatch. It’s when QA has had its say that you can put the stopwatch away for the moment.

As I like to say, productivity is not about speed. It’s about velocity. You can be fast, but if you’re going in the wrong direction, you’re not helping anyone.

Good Developers Write Maintainable Code

Hand in hand with writing less bugs is writing understandable maintainable code. As soon as a line of code is laid on the screen, you’re in maintenance mode on that piece of code.

Code that is brittle and difficult to change wastes hours and hours of developer cycles when trying to amend a system with updates and new features. By writing maintainable code, a good developer can make these changes more quickly and also improves the productivity of his or her team members who later have to work on such code.

Good Developers Do More With Less Code

Another hallmark of a good developer is that they know when not to write code. As a friend always tells me

Why build what you can buy? Why buy what you can borrow? Why borrow what you can steal?

With a few exceptions, the NIH (Not Invented Here) syndrome is a pathological productivity killer. I’ve seen developers start out to write their own form validation framework until I point out that there is already one built in to ASP.NET that does the job (It’s not perfect, but it’s better than the one I saw being written).

All of that time spent reinventing the wheel is wasted because someone else has already written that code for you. And in many cases, did a better job as it was their only focus. In such a situation, finding an existing library that gets the job done can provide a huge productivity boost.

The caveat in this case is to be careful to avoid non-extensible and rigid 3rd party libraries, especially for very specialized requirements. You might a lot of time trying to fit a round peg in a square box.

Even when you must invent here, good developers tend to write less (but still readable) code that does more. For example, rather than build a state machine to parse out text from a big string, a good developer might use a regular expression (ok, some will say that a regex is not readable. Still more readable than hundreds of lines of text parsing code).

Back to TCO

Each of these characteristics I’ve listed keeps the total cost of ownership of a good developer low. Please don’t let the term ownership distract you. What I mean here is the cost to the company for having such a developer on the payroll.

By writing less code that does more, and by writing maintainable code that has fewer bugs, a good developer takes pressure off of the QA staff, coworkers, and management, increasing productivity for everyone around. This is why numbers such as 28 times productivity are possible and might even seem low when you look at the big picture.

Hopefully seeing this perspective will convince managers that good developers really are as productive as the studies show. Negotiating a 28x pay increase on the other hand, is an exercise left to the reader.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.



51 responses

  1. Avatar for Ayende Rahien
    Ayende Rahien June 25th, 2007

    Why did you change the title? And can you answer that question?

  2. Avatar for Haacked
    Haacked June 25th, 2007

    I hit the publish button on accident. Meant to save it.

  3. Avatar for Chris
    Chris June 25th, 2007


  4. Avatar for DotNetKicks.com
    DotNetKicks.com June 25th, 2007

    You've been kicked (a good thing) - Trackback from DotNetKicks.com

  5. Avatar for Steven Harman
    Steven Harman June 25th, 2007

    Note to self: If taking another job with Phil, be sure to point to this article during compensation negotiations.

  6. Avatar for Haacked
    Haacked June 25th, 2007

    @Steve - Not sure why you'd want 1/28 of my compensation.


  7. Avatar for Steven Harman
    Steven Harman June 25th, 2007


  8. Avatar for Stephane Grenier
    Stephane Grenier June 25th, 2007

    This is by far one of the best articles I've ever read on the difference between mediocre developers and strong developers. There really is a difference and you've clearly expressed it in terms of the total ROI! Great article!

  9. Avatar for kevin
    kevin June 25th, 2007

    great stuff and you bulleted many the important developer characteristics management needs to pay attention to.

  10. Avatar for Striddy
    Striddy June 25th, 2007

    I don't doubt that the productivity disparity is real; I've seen it often enough to know first-hand. However, I have to wonder if sometimes the magnitude of the effect is skewed by the way those superdevs work and how their mere mortal colleagues are treated. Numbers like 28x stretch credulity if chalked up only to individual abilities. I think often the greater ability is recognized and magnified by the organization, be it de facto or overt.
    Take your example of going and grabbing the person who can help you get unstuck. If you're the superstar dev, that's tolerated and probably encouraged. If you're not, maybe not so much. Further, being the superstar generally garners a degree of freedom of action or <cough> empowerment, further magnifying the measured disparity in performance vs. those who are more bogged down in process and for whom every concession is hard-won.

  11. Avatar for hectore
    hectore June 26th, 2007

    Striddy, I agree that 28 times might seems a huge diff, but also consider that a dev in very few cases enters a company as the superstar, so I'd say odds are the same for any dev in a company of becoming the "superstar" or be being empowered.
    Also, I don't believe grabbing the person/stakeholder is a right only to "superstar" devs, is a practice that any dev can and must do most of the time and also is a matter of interpersonal skills to achieve it in difficult scenarios. Another skill of good devs, IMO is just that, being able to translate tech doubts into plain english and being able to comunicate properly with other techies and non-techies.
    Who hasn't heard the: "I like it when X explains things to me, I always understand him, I don't know how X does it." at least 27 times a day ;)

  12. Avatar for Dennis Peterson
    Dennis Peterson June 26th, 2007

    Excellent points all, but I don't think that's all there is to it. I think some developers really do write an incredible amount of good code in a short time. I've certainly seen some reported accomplishments by individual developers that astounded me.
    Obviously that means I'm not one of the most elite developers, at least not yet. But I'm working on getting as close as I'm able.
    At the moment I'm learning Emacs and Vim. Here's the article that got me started on that: http://derekslager.com/blog...
    By speeding up my editing, making anything I need to do almost automatic, I hope to spend more time in a state of flow (see the book by that name by Csikszentmihalyi)...on days when I'm there, I amaze myself by what I get done. Boring, repetitive work kicks me right out of it.
    Along similar lines, I'm spending more and more time writing code to generate code, instead of writing the final code directly. It takes deeper thinking up front, but then I can hit a button and all the boring stuff happens instantly, and bug-free if I've written the generator right.
    Sometimes, I convert my generator, which is like a compiler, to an interpreter, and get an extremely flexible, concise little program to do everything I need. I've had some huge wins that way. Of course, this fits in your "writing less code that does more" category.
    To get better at this sort of thing, I'm studying compiler and interpreter implementation. The more I read about programming, the more I'm convinced that building your own compiler is the programming equivalent of building your own lightsaber - you're not truly a jedi until you've done it. Here's a good article by Steve Yegge that argues the same thing: http://steve-yegge.blogspot...
    Beyond that...limiting interruptions by giving the non-programmers around me the tools they need to get things done without bothering me...and lately I'm exploring neurofeedback as a way to improve my access to that flow state. Seems to be useful so far.

  13. Avatar for Haacked
    Haacked June 26th, 2007

    @Striddy - that's what I mean by the total cost of ownership. Part of the reason a good developer is more productive overall is that a poor developer drags down the productivity of others.
    For example, in the scenario I mentioned. 2 weeks (aka 80 dev hours) went by, nothing got accomplished. Whereas had he come to me to get help, maybe taking an hour of my time, it might have taken 81 dev hours (his 80 + my 1) but the project would be complete. A huge boost in productivity.
    Productivity is not working every hour at some mad pace. It's being effective, not just efficient.

  14. Avatar for Darkthread
    Darkthread June 26th, 2007

    Excellent analysis!!
    May I have your permission to translate your article to Chinese and post it to my blog? Of course, I will give the original source url.

  15. Avatar for Haacked
    Haacked June 26th, 2007

    @Darkthread - sure. No problem.

  16. Avatar for The Other Steve
    The Other Steve June 26th, 2007

    If I've ever been 28 times more productive, it's been when someone says there's a problem, they explain what is happening and I say "Go look here."
    I'm amazed at the number of developers I encounter who don't understand how to troubleshoot.
    I had one guy working for me who rolled back all changes he made the day before because his tests wouldn't run in the morning. It turned out someone had truncated a table out of the database. But he didn't even look to see what the error message was before leaping to this conclusion.

  17. Avatar for lb
    lb June 26th, 2007

    The guy who is 28 times more productive doesn't need to be paid 28 times more than the dimwit in the next cubicle.
    The super productive guy is having a lot more fun than the dimwit. The dimwit guy finds it hard to even get up in the morning and go to work.
    The super productive guy is having a blast! Money is secondary.

  18. Avatar for Kamran Shahid
    Kamran Shahid June 26th, 2007

    Totally agreed with lb.

  19. Avatar for Ryan Cooper
    Ryan Cooper June 26th, 2007

    Great post! This is the first time I've seen someone describe the problem in language that hiring managers can/will understand. I am going to keep this bookmarked so I have some good ammo the next time I need to make this argument for hiring quality developers, even if they are more expensive.
    I think the unmeasured benefit of hiring great programmers may possibly exceed the ratios mentioned above. Great developers can also increase productivity by an amazing degree by bringing up the productivity of people around them: by troubleshooting tough problems when other developers are stuck, by spreading good development practices (like test-driven development, for example), and by helping management determine which features cost too much and deliver too little value to be worth implementing (saving what would otherwise be sunk cost and lost oppertunity cost brought about by not always working on the highest-value features).

  20. Avatar for Isaac Sacolick
    Isaac Sacolick June 27th, 2007

    I agree - but one issue good developers need to keep in mind is that their code must be maintainable by other developers. Great developers need to be fast but also develop frameworks and documentation for others to follow.
    I've seen too many fast/guru developers build up lots of code, then leave the company w/o enough knowledge passed on to the other developers. So the company gets its 10x but then loses a lot of time and possibly spends lots of money before development can resume at a reasonable pace.

  21. Avatar for programame.net
    programame.net June 27th, 2007

    Phil Haacked, un desarrollador web y bloger, ha publicado un interesante art&#237;culo sobre las caracter&#237;sticas, seg&#250;n &#233;l, que diferencian a un buen desarrollador de uno mediocre. Partiendo de una cita dle libro &amp;quot;Facts and Fallacies of Software Engineering&amp;quot; de Robert Glass que dice: &amp;quot;The best programmers are up to 28 times better than the worst programmers&amp;quot;, Phil se dedica a mencionar las caracter&#237;sticas de todo buen desarrollador que le permiten tales niveles de productividad.

  22. Avatar for Casidiablo
    Casidiablo June 28th, 2007

    Me parece un muy buen artículo.

  23. Avatar for Darkthread
    Darkthread June 29th, 2007

    Here's the Chinese edition of this article, for your reference.

  24. Avatar for CodeClimber
    CodeClimber June 29th, 2007

    Too many Code Monkeys joining the developer community

  25. Avatar for Darrell
    Darrell July 17th, 2007

    You missed some of the additional research. While *individuals* can vary in productivity by 28 times, *teams* vary by a much smaller amount. It's one of those "the wisdom of crowds" things. In the end, it's still about putting the best *team* together unless you are trying to be a one-man show - which will only work for the smallest of applications.

  26. Avatar for Nacho
    Nacho August 3rd, 2007

    I fully agree, and just post a short thought on paying developers a fair salary.

  27. Avatar for elholgazan
    elholgazan August 3rd, 2007

    Comments about this article, in spanish:
    Diez desarrolladores por el precio de uno

  28. Avatar for pablo's blog
    pablo's blog August 3rd, 2007

    Autor: Phil Haack<br />Fecha: 25 de Junio de 2007<br />Traducci&amp;#243;n: turbia.netArt&amp;#237;culo original publicado en Haacked.<br />En el libro &amp;quot;The Mythical Man-Month&amp;quot;, Fred Brooks se&amp;#241;ala una asombrosa disparidad de producci&amp;#243;n entre los buen ...

  29. Avatar for Tecnocrata Blog
    Tecnocrata Blog August 6th, 2007

    Nuevamente luego de mas de dos meses de ausencia escribiendo en este espacio, por diversos motivos, el mas importante sin duda el nacimiento de mi bebe &quot;Julio Enrique&quot; vuelvo a las escrituras:<br />Sabias ...

  30. Avatar for Tom Humbarger
    Tom Humbarger August 15th, 2007

    Great post - I just referenced it in my Catalyze blog post today about whether David Beckham is worth $250 million over 5 years.

  31. Avatar for Current Wisdom
    Current Wisdom August 16th, 2007

    In case you don't follow soccer (if you're in the US) or football (elsewhere in the world), the Los Angeles Galaxy of Major League Soccer recently lured English soccer&#160;phenom David Beckham to the ...

  32. Avatar for Jack Vamvas
    Jack Vamvas November 15th, 2007

    It's more a question of - there is a base rate that covers about 80% of tasks covered , which programmers of varying levels can manage. But then there is this extra 20% of tasks - which good programmers glide through usually with elegant solutions , whereas your lower quality programmer struggles with even understanding the concepts

  33. Avatar for any
    any November 17th, 2007

    This article is written from observational point of view.If one comes closer to the real life which means the participant point of view one will see that the real life is more relative.Everything in this article is distributed in absolute values.All the good stuff goes to the imaginery and abstract 'good developer' and then all the bad stuff is put under the so impersonalized 'not effective developer'.The life without those absolute-value glasses is far more relative which comes to tell that the distribution of bad and good features in a developer is not so one-sided and limited and often is more complex and that is the thing which makes the team oriented environment a reality.

  34. Avatar for Jack Vamvas
    Jack Vamvas December 10th, 2007

    You're definately right about the distribution of good / bad traits . On the other hand , in a typical work environment , a developer is quite often forced to implement solutions upon which they are not expert , either through a quick brain dump or wizards. Therefore the issue becomes one of more subtle nuances

  35. Avatar for Variable not found, 0:1
    Variable not found, 0:1 January 6th, 2008

    En un blog relativamente joven como este, donde el tr&#225;fico se ha incrementado de forma bastante considerable

  36. Avatar for Mark
    Mark January 12th, 2008

    "Along similar lines, I'm spending more and more time writing code to generate code, instead of writing the final code directly. It takes deeper thinking up front, but then I can hit a button and all the boring stuff happens instantly, and bug-free if I've written the generator right."
    I've been on this path myself. Compiler techniques lead to being able to perform static analysis on legacy code bases. I built a system that diagrams a legacy system and allows me to add my notes to the diagram as I go thru it. Quick comprehension of systems is real 'force multiplier'. May have commercial value.

  37. Avatar for Jack Vamvas
    Jack Vamvas January 22nd, 2008

    We did something similar to this with generating large databases around content management , 1)create the diagram 2)automatically generate the stored procedures , 3)Customise according to needs

  38. Avatar for Syed Hamid
    Syed Hamid March 18th, 2008

    A very good eye opener for dev's and managers, well if the company wants programmers to be better for their values, they must be fare to them tell them their problems, and train them, productivity will increase, sense of ownership will be knocked in, Not necessary that all the slow ones will become supers but there will be a definate change. Why re-invent the wheel, you can never be sure of what you will get. Fire those 9 others and hire 9 more to find eight still need to be fired. Train those 9 and get a better productivity and people who want to stay with you for good.

  39. Avatar for Emad Ibrahim
    Emad Ibrahim July 31st, 2008

    Excellent post. I am referring to this every time I apply for a job or try and justify my pay :)...
    There is also something that a lot of people overlook. How about the a$$h0le developer that is rude to everyone and is impossible to work with? What do you do in this case? He is an amazing developer and a superstar but his attitude destroys the entire team's morale and makes it impossible for anyone to like their job i.e. he ends up reducing everyone's productivity...
    So if he is 28x the rest but ends up reducing the morale of the entire team (made of 5 average developers) and hence reducing their productivity from 14x to 1x then the company's net productivity is a loss...
    So, managers, keep that in mind when hiring and firing... It's not just about the code and the engineering abilities. Personal skills are extremely important and overlooked by many.

  40. Avatar for haacked
    haacked July 31st, 2008

    @Emad yeah, the whol jerk developer scenario is covered in the TCO (Total Cost of Ownership). If he writes 10 times as much code, but causes the other devs to get 1/10 of their work done, it's a net loss. :)

  41. Avatar for Brian Lowry
    Brian Lowry August 27th, 2008

    Great post, Phil. Now how do we get this to managers in my area? None that I have worked for seem to grasp differences in productivity at all. I guess it is a hard thing to measure for the non-technical types.
    I'm bookmarking this.

  42. Avatar for Deb
    Deb December 23rd, 2009

    Thanks for the great article.
    In my long career, I had my fair deal of very good and very bad developers. I can vouch that the best of the lot are more then 28 times effective than the poor lot.
    Some of the common traits that I observed include:
    Extreme passion for what they do.
    They reach a level of trance, they get so engrossed doing their work that nothing on the side bothers them.
    Its more of an attitude,temperament or personal motivational. Rather than having an extra qualification.

  43. Avatar for Abdulkadir Can
    Abdulkadir Can February 8th, 2010

    Best article I have ever read about the topic.

  44. Avatar for Ray Velez
    Ray Velez December 14th, 2010

    So, two questions:
    How common are these high-performance developers?
    How do you encourage and develop these skills?

  45. Avatar for Mythical Man-Month
    Mythical Man-Month February 22nd, 2013

    Well that whole 28x pay-scale idea works at Valve, just no where else.

  46. Avatar for Patrick Morrison
    Patrick Morrison March 12th, 2013

    I just read the original study Brooks (and probably Glass) is quoting, 'Exploratory Experimental Studies Comparing Online and Offline Programming Performance'. In the 'Experienced Programmer' study, two programming problems were given to 12 participants, and measures of Coding Time, Debug Time, Size of Program, CPU Time, and Run Time were taken.   Here are the results (lifted from here: http://dustyvolumes.com/arc...

    AlgebraMazeCoding Time16:125:1Debug Time28:126:1Size of Program6:15:1CPU Time8:111:1Run Time5:113:1 
    Brooks' description is fair, but I think Glass is taking 28x out of context, based on the Debug Time measure for the Algebra program... note that the same individuals didn't get that performance boost on their coding time, or other measures. 

  47. Avatar for Ryan Gates
    Ryan Gates May 21st, 2013

    Great article. Under Good Developers Do More With Less Code, you say "the NIH (Not Invented Here) syndrome is a pathological productivity killer" but then go onto explain an example where someone created an existing framework. Should this be AIH (Always Invented Here)? Or am I missing something?

  48. Avatar for tio_ze
    tio_ze December 9th, 2013

    Reading this article I finally realised: I'm a goddamit golden god

  49. Avatar for CLynch451
    CLynch451 May 23rd, 2014

    Thanks for drawing attention to this phenomenon, and particularly the existence of "interchangeable engineer" syndrome, in which the manager feels free to shuffle his people around, assign anything to anybody, and make them work multiple projects at the same time (hey, how about 10 hours a week on these four projects? OK?).

    I have also observed that some people spend a week coding and a month debugging it, whereas the guy next to him would spend one day *designing* it, four days coding, and two days debugging.

  50. Avatar for Grant
    Grant April 22nd, 2015

    A better abbreviation for TCO is Total Cost of Outcome. Businesses are really interested in the Outcome and as you point out "ownership" only confuses the matter.

    I've worked on projects where I would sit down and think about a problem for 4 hours and then realize I could write a single line of code to solve the problem. Meanwhile, I know other developers who would jump straight in and spend days hacking the solution into a complete disaster. If you worked just on perception, some would argue I was doing nothing, when in reality I was developing a well considered solution.

    I've also spent days trying to sift through badly written code, only to give up and entirely rewrite a project in 4 hours.

    Thankfully, I've worked with top companies that recognize and appreciate this difference. You get what you pay for. Pay peanuts, get monkeys.

    This reminds of another myth called the "asian work ethic". Being seen to do work and actually doing work are very different things. Working in Singapore I would see people put in 12-14 hour days but produce very little. Just because you're sitting in front a computer tapping keys doesn't mean you're achieving something.

    Outcomes are the only things that matter.

  51. Avatar for Hanna
    Hanna August 28th, 2016

    To me, what counts is the final product. It doesn't mean I'm not interested in my people when the process is in progress as my ideal form of measuring efficiency's like this described http://www.shorelabs.com/bl... here - but the final feedback from the employed developer seems to be the most informative thing. People work in very different ways and it's easy to treat those similar to us more positively than those totally different. The leader's role is to avoid such thinking.