Productivity Variations Among Software Developers and Teams: The Origin of 10x

  1. Posted on March 27, 2008 10:15:AM by Steve McConnell to 10x Software Development
  2. Methods & Processes, Testing & QA, productivity, Management, Design, 10x, Individual Productivity, Team Productivity, Software Teams, Construction

Some blog readers have asked for more background on where the "10x" name of this blog came from. The gist of the name is that researchers have found 10-fold differences in productivity and quality between different programmers with the same levels of experience and also between different teams working within the same industries.

Individual Productivity Variation in Software Development

The original study that found huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years’ experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1; the ratio of debugging times over 25 to 1; of program size 5 to 1; and of program execution speed about 10 to 1. They found no relationship between a programmer’s amount of experience and code quality or productivity.

Detailed examination of Sackman, Erickson, and Grant's findings shows some flaws in their methodology (including combining results from programmers working in low level programming languages with those working in high level programming languages). However, even after accounting for the flaws, their data still shows more than a 10-fold difference between the best programmers and the worst.

In years since the original study, the general finding that "There are order-of-magnitude differences among programmers" has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000).

There is also lots of anecdotal support for the large variation between programmers. During the time I was at Boeing in the mid 1980s, there was a project that had about 80 programmers working on it that was at risk of missing a critical deadline. The project was critical to Boeing, and so they moved most of the 80 people off that project and brought in one guy who finished all the coding and delivered the software on time. I didn't work on that project, and I didn't know the guy, so I'm not 100% sure the story is even true. But I heard the story from someone I trusted, and it seemed true at the time.

This degree of variation isn't unique to software. A study by Norm Augustine found that in a variety of professions--writing, football, invention, police work, and other occupations--the top 20 percent of the people produced about 50 percent of the output, whether the output is touchdowns, patents, solved cases, or software (Augustine 1979). When you think about it, this just makes sense. We've all known people who are exceptional students, exceptional athletes, exceptional artists, exceptional parents--these differences are just part of the human experience; why would we expect software development to be any different?

Extremes in Individual Variation on the Bad Side

Augustine's study observed that, since some people make no tangible contribution whatsoever (quarterbacks who make no touchdowns, inventors who own no patents, detectives who don’t close cases, and so on), the data probably understates the actual variation in productivity.

This appears to be true in software. In several of the published studies on software productivity, about 10% of the subjects in the experiments weren't able to complete the experimental assignment. In the studies, the write ups say, "Therefore those experimental subjects' results were excluded from our data set." But in real life if someone "doesn't complete the assignment" you can't just "exclude their results from the data set." You have to wait for them to finish, assign someone else to do their work, and so on. The interesting (and frightening) implication of this is that something like 10% of the people working in the software field might actually be contributing *negative& productivity to their projects. Again, this lines up well with real-world experience. I think many of us can think of specific people we've worked with who fit that description.

Team Productivity Variation in Software Development

Software experts have long observed that team productivity varies about as much as individual productivity does--by an order of magnitude (Mills 1983). Part of the reason is that good programmers tend to cluster in some organizations, and bad programmers tend to cluster in other organizations, an observation that has been confirmed by a study of 166 professional programmers from 18 organizations (Demarco and Lister 1999).

In one study of seven identical projects, the efforts expended varied by a factor of 3.4 to 1 and program sizes by a factor of 3 to 1 (Boehm, Gray, and Seewaldt 1984). In spite of the productivity range, the programmers in this study were not a diverse group. They were all professional programmers with several years of experience who were enrolled in a computer-science graduate program. It’s reasonable to assume that a study of a less homogeneous group would turn up even greater differences.

An earlier study of programming teams observed a 5-to-1 difference in program size and a 2.6-to-1 variation in the time required for a team to complete the same project (Weinberg and Schulman 1974).

After reviewing data more than 20 years of data in constructing the Cocomo II estimation model, Barry Boehm and other researchers concluded that developing a program with a team in the 15th percentile of programmers ranked by ability typically requires about 3.5 times as many staff-months as developing a program with a team in the 90th percentile (Boehm et al 2000). The difference will be much greater if one team is more experienced than the other in the programming language or in the application area or in both.

One specific data point is the difference in productivity between Lotus 123 version 3 and Microsoft Excel 3.0. Both were desktop spreadsheet applications completed in the 1989-1990 timeframe. Finding cases in which two companies publish data on such similar projects is rare, which makes this head-to-head comparison especially interesting. The results of these two projects were as follows: Excel took 50 staff years to produce 649,000 lines of code. Lotus 123 took 260 staff years to produce 400,000 lines of code. Excel's team produced about 13,000 lines of code per staff year. Lotus's team produced 1,500 lines of code per staff year. The difference in productivity between the two teams was more than a factor of 8, which supports the general claim of order-of-magnitude differences not just between different individuals but also between different project teams.

What Have You Seen?

Have you seen 10;1 differences in capabilities between different individuals? Between different teams? How much better was the best programmer you've worked with than the worst? Does 10:1 even cover the range?

I look forward to hearing your thoughts.


Augustine, N. R. 1979. "Augustine’s Laws and Major System Development Programs." Defense Systems Management Review: 50-76.

Boehm, Barry W., and Philip N. Papaccio. 1988. "Understanding and Controlling Software Costs." IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.

Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000.

Boehm, Barry W., T. E. Gray, and T. Seewaldt. 1984. "Prototyping Versus Specifying: A Multiproject Experiment." IEEE Transactions on Software Engineering SE-10, no. 3 (May): 290-303. Also in Jones 1986b.

Card, David N. 1987. "A Software Technology Evaluation Program." Information and Software Technology 29, no. 6 (July/August): 291-300.

Curtis, Bill. 1981. "Substantiating Programmer Variability." Proceedings of the IEEE 69, no. 7: 846.

Curtis, Bill, et al. 1986. "Software Psychology: The Need for an Interdisciplinary Program." Proceedings of the IEEE 74, no. 8: 1092-1106.

DeMarco, Tom, and Timothy Lister. 1985. "Programmer Performance and the Effects of the Workplace." Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.

DeMarco, Tom and Timothy Lister, 1999. Peopleware: Productive Projects and Teams, 2d Ed. New York: Dorset House, 1999.

Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.

Sackman, H., W.J. Erikson, and E. E. Grant. 1968. "Exploratory Experimental Studies Comparing Online and Offline Programming Performance." Communications of the ACM 11, no. 1 (January): 3-11.

Valett, J., and F. E. McGarry. 1989. "A Summary of Software Measurement Experiences in the Software Engineering Laboratory." Journal of Systems and Software 9, no. 2 (February): 137-48.

Weinberg, Gerald M., and Edward L. Schulman. 1974. "Goals and Performance in Computer Programming." Human Factors 16, no. 1 (February): 70-77.

Channing Walton said:

March 27, 2008 1:18:PM

I've seen a number of examples where the 10:1 productivity ratio holds up, or at least it feels like it since I haven't done a formal study.

Something else I have seen on several projects is that the 10% of people contributing negatively to projects often cannot fix the problems they create. They usually rush solutions out to please managers or users, but when bugs start appearing the better guys are needed to fix them. Because these problems are usually quite difficult, they take time and experimentation to put right. The end result is that the better guys get criticised for taking too long to fix the problems!

It surprising but it only takes 1 of these guys to really damage a project.

Steve Campbell said:

March 27, 2008 1:42:PM

Grr.  Comment form ate my last attempt at this comment.  (yes, the back button screwed me too).

I think the team differences can be explained by one of two things:

1) Individuals on the teams that focus on improving team productivity (at the cost of their own personal productivity).

2) Teams that continually focus on improving themselves (contrasted with teams that are content with the status-quo).  

I think that any theoretical 10x programmer can choose to either work alone or as part of a team.  As part of a team, they can easily handle their workload within the team, while simultaneously doing tasks that improve the overall team productivity.  

It is a very fulfilling way to work, and can easily improve their (overall) contribution past the 10x point.

Kevin Fairchild said:

March 27, 2008 2:36:PM

No one is a "10" all of the time, but I think it's safe to say that some are a "1" more often than not ;)

Like an earlier commenter said, the negative impact on productivity is definitely an issue to keep in mind...

Bas de Bakker said:

March 27, 2008 2:39:PM

If some programmers have productivity close to zero, then the   variation factor can be arbitrarily large, not just 10x, but 1000x or more. So this often quoted number of 10 isn't very interesting by itself.

I'd be much more interested in the distribution of programmer productivity. Or in, say, the difference between the average programmer and the top 5 percent.

David Mathers said:

March 27, 2008 8:32:PM

Wait, productivity was based on lines of code produced? But don't better programmers use fewer lines of code to achieve the same result? I'm suspicious.

Steve McConnell said:

March 27, 2008 10:07:PM

> don't better programmers use fewer lines of code to achieve the same result?

The methodologies of the studies vary. In most cases, the programmers were given a specific assignment/problem to complete, and then the number of hours they required to complete the assignment were tracked. The number of lines of code didn't figure into the productivity results.

Steve McConnell said:

March 27, 2008 10:11:PM

> If some programmers have productivity close to zero, then the 
> variation factor can be arbitrarily large, not just 10x, but 1000x or more.
> So this often quoted number of 10 isn't very interesting by itself.

Remember that the extreme cases "programmers who couldn't complete the assignment" were eliminated from the data sets in all the studies that published enough of their methodologies to be able to tell what they did with those kinds of programmers. That amounted to about 10% of the programmers in each study, so right there you're already comparing the 10th percentile results with the top results. The fact that the 10th percentile programmers are only about 1/10th as productive as the best programmers seems pretty interesting to me.

The other thing to keep in mind is that in most cases these are small sample sets -- 20 to 50 programmers. If we were dealing with huge sample sizes -- thousands of programmers -- comparing best and worst wouldn't be all that interesting because you wouldn't run across similar size groups very often. But when you're looking at results from samples this small, the odds are you *will* run across similar results similar to what is reported in the studies.

I do agree that a very interesting number would be how productive the best programmers are compared to average/median programmers. I haven't seen any studies on that.

Tom Clarkson said:

March 28, 2008 12:10:AM

10x is about right if you exclude 10% at each end so as to include only people who approach the task in a similar way.The really bad developers can take five minutes to break the system in such a way that the entire team is working for months to fix it. At the other end you get people who will notice that large amounts of work are unnecessary.

This fits fairly well with the differences between the studies and typical software projects. The controlled task studies necessarily have simple requirements, which removes a lot of scope for both negative productivity and innovative approaches which can arise in response to complex requirements.

The Excel example also excludes the extreme cases - Spectacularly bad programmers usually don't end up at Microsoft, and a project like that doesn't offer a lot of flexibility for doing things completely differently.

I don't think we'll ever see more than anecdotal evidence of the real best and worst - We've all worked with examples of both, but they are impossible to measure in any sort of controlled situation.

Joey Sochacki said:

March 28, 2008 12:13:AM

I've heard of many variations of the differences in productivity and such, but never knew there was so much data to support the claim.

I also wonder how the best programmers can be compared to some of the average, or less productive programmers. But I certainly know that the 10:1 ratio would hold up - I've worked with a few of the "1's".

Thanks for the very interesting read.

Jurgen Appelo said:

March 28, 2008 1:47:AM has an intesting view on 10x performers. Sometimes they can be more of a liability than an asset. Superperformers can demoralize the average performers. Getting rid of the superperformers can actually increase the performance of the rest.

Antti Tarvainen said:

March 28, 2008 2:43:AM

This is a compilation paper that gives some answers to the distribution question:

According to the paper, the top 25% of programmers are in most programming tasks about five times as productive as the bottom 25%. In other development tasks (understand, maintain, review, test/debug), the difference is smaller.

Steve McConnell said:

March 28, 2008 9:29:AM

> has an intesting view on 10x performers.

Wow, I think that's a frightening point of view. He basically presents two arguments:

#1 - Super achievers are obnoxious and counterproductive. Those are prima donnas, and they're not worth the coddling it takes to keep them happy. You won't get any argument from me that. But the people who act like this aren't really top performers, are they? It certainly isn't true that every 10x developer is also a prima donna. In fact, in my experience the majority are good team players, though I have certainly seen a few exceptions.

#2 - Anyone who's significantly above average will create so much resentment within the rest of the team that it isn't worth having the star performer.

I don't want people on a team to resent super achievers. If they're resenting people who are more productive than they are, that's their problem, not the productive person's problem. I want people who *admire* the super achiever, not people who resent him/her. If I favor the resenters over the performers, I'm never going to have a high performance team.

Steve McConnell said:

March 28, 2008 9:29:AM

> This is a compilation paper that gives some answers to the distribution question

I'm familiar with that paper. He doesn't really compare the top 25% to the bottom 25%. The paper is worded in a confusing way. He compares the median of the top 25% and the median of the bottom 25%. In other words, he compares 12.5 percentile and 87.5 percentile results. This seems arbitrary to me if the point is to assess how much difference there is between the best and worst performers. If the "best case:worst case" ratio cited excludes the worst 12.5% of the worst performers and excludes 12.5%$ of the best performers, in what sense is it a best case: worst case comparison?

I can see the value in eliminating outliers, but eliminating 25% of the dataset goes way beyond eliminating outliers.  

John Gregory said:

March 28, 2008 11:45:AM

I agree there are huge disparities in productivity among programmers, or any other skill for that matter.  I have seen it first hand.  But there are many ways to "solve a problem", and it seems to me there are many uncontrolled and/or untracked factors in these comparisons.  I know when I code at times I might take as long or even longer than others, but I do more testing, create a better user interface, add more useful features and create more robust, maintainable software.  To me any true comparison of efficiency should measure these things as well.

Steve Cooper said:

March 28, 2008 2:11:PM

Does the Excel vs 1-2-3 compare the organisation's effort, or programmer effort?

If it's organisation effort, including testers and translators and project managers and usability experts, then the total time isn't really a programmer-vs-programmer comparison. It could be that Lotus's poor performance is organizational. For example, a programmer who has the spec changed on her 3/4 through a project is going to look terribly unproductive.

If, on the other hand, it's a measure of programmer effort, then it may not compare like for like. If, say, Microsoft counted internationalation staff as non-programmers, but Lotus counted theirs as programmers, then the numbers may be screwy. Similarly, are requirements gathered by analysts (non-programmers) or by engineers? (programmers)

Lastly, was lotus disadvantaged by being an older product? by being a team which has to innovate new features than one who are making a competitor copy? This applies, I think, in a lot of cases where cloning a product is easier than creating it. (Linux copying UNIX, OpenOffice copying Office, Word copying Wordstar)

Anyway, a thought provoking piece. Thanks.

Brennan Falkner said:

March 28, 2008 3:17:PM

I don't think that the disparity between 10th and 99th percentiles are very interesting..  it's going to be the same results measuring just about anything.  A graph of % of people to performance could give a real sense of things.  For instance how many bell-curves are there, where are they in relation to 1st and 99th percentiles, what factors are related to each curve, etc?  Maybe years of experience isn't correlated in any way to the absolute best programmers, but people around 80th percentile tend to have more experience.

These study 'results' sound to me like a case of wanting a good sounding headline than wanting to give useful statistics.

Steve McConnell said:

March 28, 2008 3:31:PM

> Does the Excel vs 1-2-3 compare the organisation's effort, or programmer effort?

My understanding is that this is just the effort of the dev teams, i.e., not internationalization.

Both programs were version 3, so there wasn't any difference in product maturity, either.

Interestingly, the quantitative results very closely match the layperson's perceptions of those projects.  Lotus 123 v. 3 was famously late -- it shipped at least 2 years after it's initially announced release date. Excel was heralded within Microsoft as one of the best projects Microsoft had ever done.

Bottom line: This is as a pure an apples-to-apples comparison as it's possible to get with "live" projects from real companies.

Having said that, I doubt very much that Microsoft's programmers as individuals were 10x as fast at writing good quality code as Lotus's. I'm sure there were lots of organizational factors, like how good the organization was about defining requirements. But that's really the point -- team productivity (aka organizational productivity) varies by a factor of 10 just like individual productivity does.

Steve McConnell said:

March 28, 2008 3:33:PM

> Maybe years of experience isn't correlated in any way to the absolute best programmers,
> but people around 80th percentile tend to have more experience.

Some of the studies control for experience. In the original Sackman, Erickson, and Grant study, all the programmers had at least 7 years of professional experience. So the 10:1 ratio applies to programmers *with the same amount of experience*.

Sean Murphy said:

March 28, 2008 4:57:PM

The highly effective teams I have been a member of used a rapid prototyping approach to help bound uncertainties/risks in the project and delayed making decisions when more information would improve the situation, unless any further delay was effectively a decision. It seems to me a lot of productivity comes from problems avoided by a high level of trust, cooperation, and teamwork. Also, it seems like there are broadly three classes of skills: figuring out what the customer really needs and will use, architecting a solution, and getting it debugged and into operation. I have seen folks that were excellent in one of the three areas  and good in the others, but the best teams seem to have different people taking the lead on these three aspects of defining and delivering a system.

Alex said:

March 29, 2008 3:19:AM

Then how do programmers become 10x times more productive?

John Rutter said:

March 29, 2008 7:40:AM

I think there is definitely some truth in this, even if the numbers aren't that clear.

I've been responsible for personally developing software products almost alone, which gives the best productivity - a team of ten people wouldn't have done so well. However, all of the team members would have gained if approached in the correct way.

Being a prime donna isn't always best, even if it may appear to be quickest to getting a solution. A single person, even if 10x better than the poorest, cannot scale up to take the place of large teams for increased demands and deliverables.

Those thoughts aside, building small teams with the 10x staff should bring the best of both worlds.

So how do you go about recruiting developers whose productivity and accuracy is in that upper percentile?

(final thought: all those who think that their skills, in any area, are above average - statistics means that cannot apply to all...)

George Harkin said:

March 30, 2008 11:37:PM

Needs a followup to help people/teams repair their productivity.

Paul Johnson said:

March 31, 2008 7:13:AM


Its a study of about 80 coders doing one small problem.  The results include both hours of work and SLOC produced, and there is a chart of SLOC/hour as well.

The results broadly support the 10:1 thesis.

JeanHuguesRobert said:

March 31, 2008 7:27:AM

Therefore top developers are grossly underpaid, specially when young. Right?

How can that be changed?

Jose Hevia said:

March 31, 2008 9:56:AM


If someone can do the same thing with less lines of code, he is more productive.

Measuring performance by more lines of code number is like considering a plane better than other because it weights more.

The communists in soviet Russia made this, something was better if took more resources,as Gorbachev wrote in his book Perestroika,  so tanks used 3 times more material for doing the same thing, projects took forever because then they could rise the price.

Rutger Whyer said:

March 31, 2008 10:33:AM

I'm always looking for ways to increase productivity, and would second the call for a follow-up to this with tips for better work habits. Even a plug or some pointers to sections of your books, Steve, would be appreciated. Is there a certain chapter or set of chapters in Rapid Development that you would point us to, for example?

On the reliability of the task-completion-based studies, that would depend on whether the task to be completed is a real-world problem, or a contrived exercise designed as puzzle material. I'm not convinced the mapping between those who do well at puzzle programming challenges and those who do well at work is 1 to 1. And simply completing the task with working code should not be enough. The code should be assessed for quality, maintainability, testability, and other such factors.

Rutger Whyer said:

March 31, 2008 10:41:AM

Loved this quote from the study of 80 programmers using different languages:

"In the script group, the Perl subjects may be more capable than the others, because the Perl language appears more than others to attract especially capable people."

Perl FTW.

Anthony Kimbell said:

March 31, 2008 7:20:PM

I have often encountered developers who did more harm than good.  Simply not coming to work would be an improvement.  Such people are accidental saboteurs.  Such an individual might be excellent in the extreme, in the correct environment (team, project, subject domain, language, architecture, process), but when the environment does not match their style... look out.

Gordon Guthrie said:

April 1, 2008 12:56:AM


The figures on Excel versus Lotus productivity - which of the studies are they referenced in? Boehm et al Software Cost Estimation with COCOMO II?


Steve Cooper said:

April 1, 2008 3:49:AM

> If someone can do the same thing with less lines of code, he is more

> productive.

Not so. At least, not just that, without qualifications or further comment.

The first problem is time. If I can write 200 compact lines in an hour, or 300 verbose lines in an hour, then I'm equally productive down both paths. Same number of features/unit time. And the 300-liner will possibly be easier to follow. It's only when I can write these 200 lines in <1hr that I am more productive.

Second, the only real way to compress code is to find and use an abstraction -- eg, writing functions which are used several times rather than duplicating code. You can only compress if there is duplication in your codebase. Once all the duplication is out, there is no shorter way of expressing the algorithm. So 'more with less' only holds if you've missed abstractions. Basically, you can only compress code if you've failed to follow the DRY principle. For two programmers who follow the principle, the one who writes more lines is getting more done.

The last important variable is language. Some *languages* let you code better abstractions, which lead to shorter codebases. But comparing two programmers on the same project and in the same language, neither of them has a linguistic edge over the other. In this case again, more lines tends to mean more features.

So I can't agree with your statement, but would add this as an alternative;

"if you can get the same features, in less time, in the same language, you are more productive"

> Measuring performance by more lines of code number is like

> considering a plane better than other because it weights more.

Or possibly you're comparing *total weight of planes built*. If the planes are comparable, more weight is better.

Steve Cooper said:

April 1, 2008 3:51:AM

> team productivity (aka organizational productivity) varies by a factor of 10 just like individual productivity does.

Yeah, and I think this is probably the most interesting part, for me, because it's the real-world metric that matters most. "Are you guys going to deliver in June, or October?"

Steve McConnell said:

April 1, 2008 12:10:PM


The Excel numbers are from Microsoft Secrets by Michael Cusumano, “Shipping Software on Time” videotape by Chris Peters, and unpublished Microsoft memoranda describing the Excel 3.0 project. The Lotus 1-2-3 numbers are from an article in Fortune Magazine, September 25, 1989, pp. 100-112.

Lance Walton said:

April 1, 2008 6:58:PM

My experience is consistent with the points made in this article.

The conclusions to be drawn from the Excel / Lotus 123 paragraph are a little unclear to me; the article generally argues that better programmers produce smaller programs to achieve the same  (or better) results. It seems that the Excel guys produced more code in less time, so I'm not sure whether that makes them better or worse - I've never used Lotus 123, so I don't know whether it was a better product or not. The fact of Excel's continued existence and popularity compared to Lotus 123's decline are not necessarily an indication of Excel's superiority.

John Rutter's 'final thought' actually goes a little deeper than statistics. The, by now surely infamous 'Unskilled and Unaware of It' paper ( shows the dangers of self-evaluation pretty clearly.

Jean Hugues Robert's (rhetorical?) question about top, young developers being especially underpaid is interesting. The original article says that the Sackman, Erikson, and Grant (1968) study found 'no relationship between a programmer’s amount of experience and code quality or productivity'. I wonder whether a relationship would emerge if only the best programmers were considered; my experience has been that something that frequently goes together with a good programmer (and frequently lacking in the ummm... less good) is a restlessness about the state of their art and a need to learn better ways, often at a fairly fundamental level. This is expressed more lucidly by Channing in which was originally triggered by Kathy Sierra's article found at

JeanHuguesRobert said:

April 2, 2008 2:14:AM

"Top young developer especially underpaid".

@Lance Walton: I am on your side. Being 42 now, and still enjoying programming, I can 100% assert that my coding style is much better today than it was 20 years ago and I keep looking for new ways to improve it. OTOH I cannot code half the time I could back then and it gets harder and harder to enter "the zone" :-(

So, overall, I stand on my position that young top programmers are especially underpaid. When they get older, they manage to get a slightly better salary than the average guy, but not at all in proportion of their efficiency.

So, old top developers are grossly underpaid too!

Steve McConnell said:

April 2, 2008 9:27:AM

> The conclusions to be drawn from the Excel / Lotus 123 paragraph are a little unclear to me ...
> the Excel guys produced more code in less time, so I'm not sure whether that makes them better or worse

All other things being equal, more code in less time is better. (And when I say "all other things being equal" I'm including quality of the code and the amount of functionality produced by equivalent amounts of code.)

In this case, the factors that weren't equal were pretty strongly in Excel's favor. Excel 3.0 was a huge success in the marketplace. It got terrific reviews in the computer magazines at the time. It was essentially the version that catapulted Excel into the position of market leader. (1-2-3 had been in the lead prior to the release of Excel 3.0.) Lotus 1-2-3 version 3 was a famously challenged project and basically hit the marketplace with a dull thud.

Overall, the Excel team wrote more code in less time and produced a better product. I think it's a true 10x difference in productivity, or even greater if you consider the quality of the released product.

Lance Walton said:

April 2, 2008 1:47:PM

OK Steve, thanks for the additional context - it completely clarifies the point for me.



John Rutter said:

April 4, 2008 6:06:AM

@Lance Walton - interesting article, with their point being that those who are 'less competent than their peers' in a topic will even less accurately rate their own abilitiy.

I still think the most telling point is that *all* of the people questioned on their perceived ability put themself 'above average', which just cannot be right.

That the report shows a greater difference between the perceived/actual abilities at the lower end of the scale may also be affected by any modesty that could be exhibited those at the upper end of the scale.

Having said that, I am sure I am in the upper percentiles for my coding abilities ;-) and claim that I have been in that position over at least the past 25 years of my technical career. No modesty here!

@JeanHuguesRobert And I used to be paid more for that ability. I now get paid less for 'managing' teams of developers with mixed skill levels (glad to say, many also being top guys). Now how does that work out in terms of career progression. Don't answer that.

Lance Walton said:

April 7, 2008 1:43:PM

@JohnRutter: Agreed that everybody put themselves above average.

It is of course possible for most people to be above average if the distribution is severely skewed, but it is not possible to skew it enough for everyone to be above average - at least one person would have to be vastly below average. Presumably that person's meta-cognitive skills would be so lacking that they'd be one of the most arrogant ignoramuses in the history of stupidology.

riya said:

April 14, 2008 8:04:PM

how do we calculate the productivity pf a programmer x who has done module 1 p lines in 2 days and module 2 k lines in 3 days

Guillermo Schwarz said:

April 15, 2008 2:06:PM

About the 10% of programmers who couldn't complete the assignment, a few years ago I interviewed 100+ Java developers.

I asked them to reverse a String.

Half of them couldn't complete the assignment and 80% of that half didn't even try.

The test has 24 questions. Only one developer replied 22 correctly but we couldn't afford him. The second best answered 18 correctly and was affordable.

The developer with the lowest ranking that was hired only had 5 correct answers of 24, and the project was a huge success.

Management was totally surprised by the high level of productivity (measured in use cases per month), by the quality of the product and the incredible team motivation.

All we did was to hire the best our money could buy, give them powerful machines, compile automatedly with ant, run unit tests with junit, and functional tests with selenium.

There were other tricks like doing prototypes and converting them into libraries, reducing code duplication, having written and updated code conventions, doing a code review before any check-in, having a team leader in each layer, etc., but having the best people was clearly our most important asset.

AmazingMo said:

April 23, 2008 9:16:PM

Joel Spolsky makes a corollary to this point in his blog post "Hitting the High Notes".  Joel focusses on the difference between programmers who can solve hard problems, and those who can't, but he also has some data that supports the 10:1 case along the way.  If you've read down to this point, you probably will want to look for Joel's post too.


Post a Comment:


Steve McConnell

Steve McConnell is CEO and Chief Software Engineer at Construx Software where he consults to a broad range of industries, teaches seminars, and oversees Construx’s software development practices. In 1998, readers of Software Development magazine named Steve one of the three most influential people in the software industry along with Bill Gates and Linus Torvalds.

Steve is the author of Software Estimation: Demystifying the Black Art (2006), Code Complete (1993, 2004), Rapid Development (1996), Software Project Survival Guide (1998), and Professional Software Development (2004). His books twice won Software Development magazine's Jolt Excellence award for outstanding software development book of the year.

Steve has served as Editor in Chief of IEEE Software magazine, on the Panel of Experts of the SWEBOK project, and as Chair of the IEEE Computer Society’s Professional Practices Committee.

Steve received a Bachelor’s degree from Whitman College, graduating Magna Cum Laude, Phi Beta Kappa, and earned a Master’s degree in software engineering from Seattle University.
Contact Steve