Forbes is wrong about “Developernomics”

Forbes is wrong when it says:

The thing is, software talent is extraordinarily nonlinear…It’s still a kind of black magic…the 10x phenomenon, and the industry’s reliance on it, doesn’t seem to get engineered or managed away. Because the 10xers keep inventing new tools for themselves to stay 10xers…

This is folklore, not science, and it is not the view of people who actually study the industry.

Professional talent does vary, but there is not a shred of evidence that the best professional developers are an order of magnitude more productive than median developers at any timescale, much less on a meaningful timescale such as that of a product release cycle. There is abundant evidence that this is not the case: the most obvious being that there are no companies, at any scale, that demonstrate order-of-magnitude better-than-median productivity in delivering software products. There are companies that deliver updates at a higher cadence and of a higher quality than their competitors, but not 10x median. The competitive benefits of such productivity would be overwhelming in any industry where software was important (i.e., any industry); there is virtually no chance that such an astonishing achievement would go unremarked and unexamined.

This folklore arises, in part, because it is possible to be arbitrarily more productive than the worst. The software industry is no different than any other in terms of the “Peter Principle” of people rising to their level of incompetence: developers who succeed tend to move on to work on larger, more complex projects and, regrettably, not every developer or development team understands that different techniques are required at different scales. The tools and techniques that suffice for 5,000 lines of source-code don’t suffice for 50,000 and what suffices with 50,000 don’t suffice with half-a-million. The totally competent at one level of complexity may totally fail at the next. One of the depressing realities of being a software development consultant is regularly walking in to these situations, with their broken morale, finger-pointing, and distrust. 10x more productive? Nonsense! You’re dividing by zero!

Sure, there are tasks at which one programmer may well be an order of magnitude faster than his or her colleagues. Being well-practiced in a technique or the use of a component can easily lead to such gains. It’s difficult for non-developers to understand how fundamentally plastic software is; a programmer can deliver a feature in any number of ways and even when there is broad agreement about an overall approach, there is a vast advantage in knowing “these two components turn out to be incompatible” or “that answer is easily provided by this library.”

How do task-based advantages play out over the course of, say, a year? No one knows: I’ve never heard of a study that tried to quantify developer productivity over such a long timescale. The problem of even defining productivity at such a timescale is ample cause for argument. Professional software development is a team sport, and most development managers have experienced a trade-off of a developer with technical skills but less-than-desired soft skills. Conversely, time spent away from the keyboard actually working with users often leads to far more value than would be achieved by coding away and checking later.

None of this is to say that there are not individual differences in productivity. Based on the programmers I’ve met over the course of 20 years of working with software teams, I think that over long timescales, the top 5% of programmers are probably 2-3x as productive as median programmers (and I don’t think anyone in industry is 10x median: industry couldn’t provide sustenance for such a creature). I tend to think that this is a combination of inherent talent, the speed with which they can switch between tasks and techniques, and temperament.

I get stirred up about this folklore because it has major consequences. An industry where excellence is 10x median performance ought to be structured very differently than an industry where excellence is 2-3x median.

Variations in productivity compound: over the course of several release cycles, even in a world without super-programmers, the excellent team can crush the less-the-average (even putting aside the uncommon, but not vanishingly rare, competition that truly has zero productivity or is even in negative making-things-worse mode).

But even if there are real super-programmers, Forbes still is wrong about “developernomics.” The real issue in software development is which of these two charts correctly describes the cost of fixing a defect over time:

The first is the Boehm curve and the second is the Beck curve. The Boehm curve describes the view presented in “Software Economics” and holds that the cost of fixing a defect rises exponentially over time: it is cheap to correct a mistake when sitting around a table gathering requirements, more expensive to fix during initial coding, more expensive to fix late in testing before release, very expensive to fix after release. The Beck curve describes the view presented in “Extreme Programming Explained“: while it’s still cheapest to fix a mistake before a line of code is written, fixing a two-year-old defect in production code is not really *that* much more expensive than fixing the defect 10 minutes after it’s first introduced into code.

There is much to be said about these curves, but the crucial point is this: individual programmer excellence, whether 10x median or 2x, does not drive organizational software productivity. Any team, no matter how talented the individuals, whose costs follow the Boehm curve will, over time, lose to any team, no matter how mediocre the individuals, whose costs follow the Beck curve. It’s just a matter of where the cross-over occurs.

Does industry have teams whose costs follow the Boehm curve? Yes, absolutely. Does industry have teams whose costs follow the Beck curve? I’m not sure that the constant-over-time flatness is realistic, but absolutely teams can bend the curve towards the ideal. Call it “process-nomics” or “team-nomics” or, hell, call it “developernomics” because it is developer-centric. The problem with the Beck curve from the management perspective is that to achieve that curve, you have to give up traditional project management controls. Gantt charts don’t work with agile development. You can’t do fixed-price, fixed-feature, fixed-time budgeting. You can’t sign off on requirements and wait around for teh awesome to appear under the Christmas tree.

Management hates giving up that stuff so much that they would rather continue chasing unicorns and 10x super-programmer teams and magical complexity-free programming models. So now, because of this stupid Forbes article, you’re going to have to explain to your bosses why it’s stupid and off-putting to write a “we’re looking for rockstars!” job ad and why you shouldn’t either jump on the first “ninja” to walk in the door or spend a year filling a position and they’re going to be pissed when you ask the obvious “if you believe this, then which of our developers is going to be paid $700,000 per year?”

And the fact that they don’t structure salary like that? It shows that, not far from the surface, they know its bullshit.

Update: If the subject’s of interest to you, you might enjoy (or despise) the column on the subject I’ve been writing for SD Times for the past decade.

Update: A little less rant-y follow-up post Why 10x Ticks Me Off

Update: Moneycode vs. Developernomics

37 thoughts on “Forbes is wrong about “Developernomics”

  1. I do believe that the best programmers are 10x better than the worst programmers. There are some editors that cannot understand the difference between worst and average and unknowningly let an article such as the Forbes article pass by without question. Un/fortunately, given management beliefs (why would they get more than 10x the pay of the average worker) this myth will get some legs.

  2. “Professional talent does vary, but there is not a shred of evidence that the best professional developers are an order of magnitude more productive than median developers at any timescale, much less on a meaningful timescale such as that of a product release cycle. There is abundant evidence that this is not the case: the most obvious being that there are no companies, at any scale, that demonstrate order-of-magnitude better-than-median productivity in delivering software products.”

    I don’t know whether your conclusion is right or wrong, but your argument doesn’t establish it. Please see

    http://en.wikipedia.org/wiki/Fallacy_of_division

  3. @Willie : Valid criticism. Truly arguing the case is a vast undertaking and this post was a rant, not a scholarly essay. Let me just say that at the level of empirical studies, I believe that Barry Boehm’s work is foundational but cannot be reduced to a single number (or rather, is misleading if reduced to a single number). I am a big fan of the continuing work of Lutz Prechelt, but his work is still very small-scale and I believe that so far he has confined himself to studying students. (I would submit that it’s reasonable to wonder if the distribution of talent in industry with more than, say, 5 years experience is the same as the distribution in talent in college.)

    As for the fallacy of division, I certainly rapidly shift between issues of “super-programmers” and “super-teams” in the rant. Super-programmer teams have been tried and have shown no compelling benefits.

  4. @Willie

    I caught that too. But that’s because of the implicit premises in the argument that Larry is trying to refute. Larry, I think they go something like the following

    1) Average productivity is (non-uniformly) randomly distributed across the population of programmers (this is necessary for the 10x theory to be true and useful).
    2) If 1, some companies will have a significantly larger proportion of 10x-ers than others.
    3) The productivity of a team of programmers is very strongly correlated with the productivity of its members.
    4) If 1,2,3 then by mere chance some mostly indistinguishable teams will see massively higher productivity than others.

    That’s basically the argument that Forbes commits itself to which Larry refutes.

  5. Any time I see someone dispute the 10x programmer, I assume they: a) have not worked in the software industry for very long, b) have worked in IT departments instead of high tech, and/or c) are overcompensating for some real or perceived shortcoming in their own talent.

    I’ve been doing this long enough to have seen a handful of 10xers. In each case it can be proven quantitatively (e.g. lines of code, stories points per sprint, defects per sprint), and qualitatively (e.g. innovation, patents).

    Behind almost all the great software products of the software age (e.g. Apple OS, Apache, Viscalc) is almost always one or two 10x programmers.

  6. @Joe Sold my first program in 1980 at age 16, Editor of Computer Language and AI Expert at 26, launched Internet gaming company in 1995, VP of R&D in a Dot-Com Rollercoaster, architected and developed the core components for systems that are now transacting >$600M / yr in sales, at age 40 moved to an ocean-view house in Hawaii, currently in a 2-yr contract as Senior S/W Engineer at an 8M telescope. I think I’m at least a median programmer.

  7. Thanks for your response.

    You claim that there is not a “shred of evidence” for my claims and lots of evidence that this is “not the case.” You also focus your entire argument on the idea of “productivity.”

    Though Brooks’ original argument may have been stated in productivity terms, and most people who talk about the 10x effect use rhetoric like 5000 lines of usable code vs 500, this does NOT mean that they are actually talking about measurable productivity in a bug-free-lines sense or any other such sense.

    They are talking about people who have the insight to ask the right design and architectural questions, frame problems correctly (including correcting non-technical managers who ask the wrong questions) and most importantly, manage to pose and solve problems that others can’t even see.

    This is perspective and creativity, not productivity in an assembly-line sense. But the impact of having such people on your team is immeasurable. They create amazing apples when apples are in demand, where others create average oranges, in response to management mistakenly asking for bananas.

    Given that the evidence is qualitative, it makes sense that you will not find it if you go looking with quantitative tools and graphs. You need an ethnographic/narrative approach to get at the evidence of existence of 10Xers.

    Why am I so confident they exist? Because I’ve met them in every single job, and encountered them in every single amazing software success story (even discounting the natural tendency to build up individual heroes to valorize over teams). They don’t show up in aggregate or statistical measures because they are such a small part of the population, and may do so little actual work, but the work they DO do is at the basis of all the work done by hundreds of others.

    I agree that the term 10Xer is bad because it encourages the industrial age metaphor of quantitative comparison. You end up imagining Lucy on the chocolate factory assembly line and some super-human who is able to wrap chocolates 10X faster than Lucy.

    No, software is NOT assembly line work done in individual, separate broken-down units. It is a very deeply coupled complex system. That’s why the other thing Brooks is famous for is the Brook’s law that adding programmers to a delayed project can make it even more delayed. He analyzed that effect deeply and concluded it is due to coupling, communication etc.

    In this context, what 10Xers manage to do is get the topology of the software engineering network right by building the core pieces right, partitioning things in the right way, coupling things correctly etc.

    Fundamentally, this is an anthropology question more than a lean six-sigma type process question. Perhaps this is why the preferred terms these days are things like Ninja or Rockstar rather than 10x, getting at the fact that the 10x effects come from unique abilities to play the most mission-critical and high-leverage roles within a complex system of people, tools, toolchains, production operations, support, bug-fixing…

    There is a joke that illustrates all this perfectly. A guy has a broken-down car and goes to a mechanic. The mechanic opens the hood, stares for a minute, and then tightens one nut. The car works perfectly. The mechanic says, “That’ll be $100.” The customer is outraged, “You just tightened a nut!” … the mechanic writes up and offers an itemized bill: “Tightening nut, $0.01. Knowing which nut to tighten: $99.99.”

    Would you rather have this mechanic or somebody who goes religiously and thoughtlessly (but efficiently and diligently) through the whole repair manual and figures out which nut to tighten at the end of hours of expensive testing?

    10Xers are those who know which nut to tighten.

  8. There are many programmers who make a net negative contribution to the project and code-base and of course those who make a net zero contribution. It’s no so much that there are super rock stars, more that there are many people whose contribution is extremely poor or downright negative.

  9. ” Super-programmer teams have been tried and have shown no compelling benefits.”

    Really? Even for a rant that’s a strong statement.

    I have a seen a very few examples in the wild where a small group of very competent developers /with the right culture/ have creamed the opposition. The classic example is Jim Coplien’s case study of a Borland team, or Paul Graham’s stories about his lisp days. I worked for one company that kept the number of its developers a secret because no-one would believe how few they had.

    The real problem, as you point out, is that there are very few organisations that are tuned to take advantage of such a team, except perhaps start-ups and the occasional enlightened genius. The rest continue to waste oceans of money because their “reality” blocks them from understanding the true economics of software.

  10. Your point about the economics of 10xers is invalid. I personally know senior engineers at Google who have been granted $5-8M retention packages that vest over 4 years. That works out to substantially more than the $700,000 straw man figure you offer.

  11. The slowest programmer takes infinitely long, so fastest:slowest discussions are meaningless. A horse will take infinitely more time than I will. I have personally witnessed an infinitely slow coder: one of the consultants just never checked in his code, ever.

    Thus the only sane thing to discuss is median:fastest. There, the academic literature shows about a 2-4x speed improvement. Also, in the (very small numbers of) studies which look at multiple tasks, it was easy to spot the worst programmer, but much harder to identify who was the best. Different people did “best” on each of the tasks, some were more consistent, etc.

    See
    http://blog.webfoot.com/2008/02/06/vandev-talk-summary/
    for a bit more in-depth discussion.

    Furthermore (and I don’t think I talk about it in my blog post above), programmers dont’t spend all their time writing code. There is design, testing, planning, searching for the right place to put the code, meetings, reading API docs, bug fixes, documentation, etc. Andrew Ko did some studies of professional programmers, and found that they spent some pitifully small fraction of their time actually writing code.

  12. While I like the article for its virtue of not buying industry folklore without evidence and raising discussion points, I disagree with it in MANY places. Examples in no particular order:
    1) “And the fact that they don’t structure salary like that? It shows that, not far from the surface, they know its bullshit.” HR and management who do salary structuring have not in any company I have collaborated with or worked in understood a rats ass of who really adds value and how. Managers tend to come with economics backgrounds or are pushed into management because they are technically useless. The rare bunch of techies in management (who quickly deteriorate) are the ones for whom only path to get more salary has been to go into a managerial position, which leads the most senior and skilled programmers to quit doing what they are best and most productive in and start doing pointy-haired-boss Power Point crap. Destructive for the company in many ways, and yet very common. (They do it when they get children, large mortgage etc. for entirely financial reasons. Modern day organizations do this because they do not have career-paths for “super duper coding architects”, because they don’t know any better. Because they choose to believe that fiddling with Power Points adds value. Your belief in the sharp heads in management in these issues is against anything I have witnessed in my over 10 years in the industry. Good for you if you have seen smart company management layers.)
    2) The productivity “2x” – claim. While I agree with your good point that evidence of 10x productivity should be put on the table, I claim that combining inexperience/lack of motivation in 1) technical environment understanding (quirks of the stack/data/integrations etc. at hand) 2) good architectural solutions (oh the ways a person can code a minor part or a whole solution to be a horrible spaghetti/dead end/maintenance hell requiring HUGE refactoring or solution replacing) 3) business environment understanding (what actually adds value/is what the business needs in the particular field) cause delays that are HUGE and can lead to failures of individual tasks or even IT projects (ever seen a failed data storage solution?), in which case at least average, if not median do fluctuate towards WAY larger coefficients than 2.

    Now, another question is, whether there really are super programmers that are super duper 10x more productive ACROSS ANY BUSINESS OR TECHNICAL ENVIRONMENT. I don’t think so. If there were, yes, you could just buy a dozen of them and solve all the world’s problems. That definitely is not happening in the environments or companies I have seen, although there are some small companies with vastly superior general level of craftmanship than say, an equal number of random TCS/Accenture consultants.

    Thank you for your post, I like it, even if I don’t agree with it that much. My experience points to another conclusion.

  13. You are claiming to argue the facts, but there is not a shred of evidence that what you say is correct. Where are the citations?
    And, you bizarrely avoid mentioning the seminal work on this topic, The Mythical Man-Month.
    Also, cost of change over time is all about software processes, not the individuals. The exponential graph is from the waterfall process.

  14. @casey This was definitely a rant, not an essay. I jump between topics, I don’t cite, etc. It’s interesting that I write about this every month in my column for SD Times, but it is this emotional rant that attracted the attention of hackernews.

  15. Larry, you are right that there are a lot of fairy tales in this industry, especially in discussions of labour economics.

    But you seem to place a lot of emphasis on formalised study of productivity, especially by academics. Unfortuantely software as a field is too young to have evolved accepted markers of status and capability that are accessible to outsiders, and thus studies by academics and economists are not authoritative.

    The argument that great developers aren’t recognised by industry or by company success is simply not true. Large firms are starting to pay high (seven-figure) packages to top developers, and the flood of startup investment is more evidence of this trend. Indeed, that’s part of Venkat’s theme in his Forbes article.

    Google, Microsoft and Apple grew from nothing to remarkable valuations in a decade or so, while competitors have flailed. Although there are many factors at work, a common one seems to be that the developers in those companies were extremely good. There would probably be many more company successes if highly productive developers weren’t constrained by out of date managements. That, again, is another of Venkat’s themes.

    In my own experience, I’ve seen many cases of talented individuals rescuing disasters created by large teams, and recognising and avoiding complications in requirements, planning meetings and engineeering. I have no problem with the claim that some developers are an order of magnitude more productive than the median.

    I think what we’re seeing is a fascinating industry inflexion point where developers are starting to understand their value and demanding they receive it. There have been four articles on this subject recently.

  16. Sorry to spoil your rant, but I wanted to repost/rewrite a comment I just wrote on Hacker News that kind-of invalidates your thesis:

    In the area of debugging games, I have been EASILY 10x more productive than the developers I was supporting in finding bugs in their code. In fact, you could say infinitely more productive, because they would typically spend hours or days trying to find the bug, and the only reason I’d ever see it is that they failed to find it.

    I was the architect of the underlying game engine used by a casual game publisher, and I was the last line of defense if one of our developers got stuck. Most of the bugs weren’t even related to my engine, but were deep in their game code, which I typically had never seen before I dove in.

    In one case a developer had been trying to find a bug for weeks when they finally punted to me. I had it fixed in a half hour. I never spent more than a day finding one of these “impossible to find” bugs, and 95% were fixed in 1-3 hours.

    These are all developers who otherwise are at least average, and possibly above average. We certainly ran them through technical interviews and determined they were at least competent to begin with, and they DID all eventually ship games. So you can’t tell me that 10x average doesn’t exist, at least in particular areas of expertise.

    If you wanted me to write a CRUD app, or anything in Rails, though, it would take me a while to get up to speed. But in games that I write myself, my change curve looks much more like the Beck curve; I just made a pile of changes to my latest game as it got a new publisher, and it took me three weeks to completely overhaul how the main user interaction functioned, as well as adding a pile of new features. After submitting a half dozen bugs, the publisher QA lead reported to the producer, “Damn, Tim is fast,” as I’d managed to fix 5/6 bugs he’d reported within 30 minutes, and the other one took me an hour.

    So AM I a 10x programmer? Probably not all the time, but certainly sometimes.

  17. How do you explain these results?

    http://code.google.com/codejam/contest/scoreboard?c=32016#vt=1

    you might notice that these are pretty standard, and the median score is only completes 1/3 of the test and does so in 6-8 times as long. I would point out the programmers competing in this would standardly be above the normal programmer out there.

    I would also point out that you seem to disprove your own argument in your argument. If a programmer can archive the beck curve, it would seem that they would be at least 10x as productive. or do you believe that achieving the beck curve is just ‘luck’ and has nothing to do with programmer skill?

  18. also:fixing a two-year-old defect in production code is not really *that* much more expensive than fixing the defect 10 minutes after it’s first introduced into code.

    are you old enough to remember the year 2000 bug? do you really think that was “not really *that* much more expensive” than if 10 minutes after they introduced they said – wait, let’s make that a 4 digit date.

  19. > the most obvious being that there are no companies, at any scale, that demonstrate order-of-magnitude better-than-median productivity in delivering software products

    This is completely wrong; the software-production efficiency of companies varies by more than an order of magnitude. You just don’t see the ones at the lower end of the scale (which failed to attract enough 10Xers) because they fail in the marketplace.

  20. I know a lot of programmers who did more than 700000$, just working in high dynamic startups, not in big organizations that cannot take advantage of their skills.
    Moreover, good luck to implement the Beck’s curve with your average Joe programmer.

  21. @Uberto and @ A Googler: Compensations like that are enormously out of line with salary surveys (PayScale, Software Development, Computerworld). Perhaps they are a new phenomenon. As for the “dynamic startups” that pay more than $700K: real startups plough what little money they have into growing the company and increasing internal equity share. If anything, destined-for-success startups can retain their excellent people for less, since they offer better working environments and a better eventual payoff.

  22. @James : Yes, the issue is whether the best companies or programmers can exceed 10x medianperformance, not the performance of failed or failing companies. Of course, this assumes that median company productivity is not bogged down and that median programmer productivity is not incompetent; in my opinion, median teams muddle along and median programmers are smart and competent. I should plead guilty to implicitly ignoring the outsourcing boom that produced millions of under-trained people labelled “programmers” and hundreds-if-not-thousands of companies with “throw people at it” programming models.

  23. @llewellyn The Y2K bug played out per Boehm’s cost arguments. The Beck / agile cost curve arose in the atmosphere of crisis engendered by Y2K.

  24. @llewellyn “If a programmer can archive the beck curve, it would seem that they would be at least 10x as productive.” No, their team would be (well, the multiple wouldn’t matter: changing the cost-curve of defect correction / feature creation is the only way to “win” in software productivity). Absolutely I believe that skill plays a role in success, but not the overwhelming role of the Superprogrammer myth. Organizational and process structure and team dynamics are more important. Believing in Superprogrammers distorts the industry, just as shows like House or CSI distort the truth of the industries they portray. Such myths are fun to believe, but if they are acted upon as business rules, they can lead to disaster.

  25. @Tim: Your story rings very true. But you seem to acknowledge the dependence on the context. Perhaps you would acknowledge that one of your fellow programmers who cannot work on the engine at your rate might create his or her own engine on which you would not be as effective. If you agree, then perhaps you can see why I feel strongly that telling companies that “Tim is 10x better than Charlie and that’s the way of the software world” is bad for the industry: it’s a distortion of the talent and value of both you and your fellow developers. Your model brings up a very interesting question though and is what I got to when I wondered “How do task-specific advantages accumulate over time?” Many software projects structured such as yours eventually face a problem in that the architect / lead programmer becomes a bottleneck — you should be working on new features, but there’s pressure on you to exploit your task-specific to fix defects. Again, I would say that the 10x Superprogrammer myth is harmful there: “Tim’s a 10x Superprogrammer and we simply _must_ put him on the most pressing problems at all times.”

  26. @Tony Well, it may be that there’s been a seismic shift in compensation strategies that has not yet been reflected in salary surveys (for instance, http://www.pcworld.com/article/230169/google_leads_tech_salaries.html) . The market is definitely frothing right now and it may be that some developers are getting such high offers. (Although: From whom? What kind of excellent programmer would go to a startup that is treating its investment cash like that?) On your “I’ve seen talented individuals…rescuing disasters…” I agree that such rescues happen all the time, but I do not believe that such rescues arise from individual programming talent, I believe they arise from a combination of talent, discipline, knowledge, and I believe that the discipline and knowledge aspects can be transferred. And I don’t believe that the talented person who rescues one organization is necessarily capable of rescuing any organization. I think that such a mental model (10x Superprogrammers) does our industry great harm.

  27. It’s not just that better programmers get more done in less time. They are *capable* of more possibilities. Crappy programmers can’t code their way out of a paper bag, gurus can build software empires. That’s the 10x kicking in, again and again

  28. Reading your response to @Steve I realized my mixed feelings about your article. I’m absolutely against the Superprogrammer/Superstar model, still I believe there is an enormous difference in productivity among programmers.

    The point is, to create a team like the Borland one, one have to pick up its dev very carefully, be ready to pay them slightly more than the market average (no 10x of course) and don’t let them go.

  29. Regarding: “…there is not a shred of evidence that the best professional developers are an order of magnitude more productive than median developers at any timescale, much less on a meaningful timescale such as that of a product release cycle”, McConnell has compiled a number of study sources over the years that suggest otherwise:

    http://tinyurl.com/353svp

    “…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).”

  30. @ewb McConnell defends 10x best:worst (although he notes that studies generally throw out “did not complete”). I think he generally defends best:median more in the 5x range (which I think is still too high). He is clear that he believes that team-based advantages can be learned. Although his list of citations may initially look decent, there is a noticeable criticism by Laurent Bossavit http://www.readability.com/articles/5egv0hme?legacy_bookmarklet=1 (I’ve known McConnell for 20 years and feel the aspersions against him are incorrect, but the criticism of the citations has validity). This would be a good point to also acknowledge that Capers Jones work also needs to be read and can be misinterpreted to support very high variances, but only if one ignores context (i.e., if one compares the rate at which large systems are built versus the rate at which small systems are built, you might say “companies that build small systems are 10x (or whatever) more productive than companies that build large systems.” It is certainly true that small systems are very much easier on a per-LOC basis than large systems: but that is an apples-to-oranges comparison).

  31. @ewb This might also be a good place to state that I believe that the software industry has changed dramatically since the Internet boom and I think that, at this point, both the composition of the professional programming industry and the ways in which software is built by the industry are quite different to those things in the 60s-early 90s. I think, in general, software practices are much better than they used to be and that the knowledge of good practices is much more broadly distributed. So it may not be very worthwhile to see what can be parsed out of data generated before the rise of the Web.

  32. Whether the top programmer is 10x better than the median is not the question that matters. What really matters is how many people on the team are negative producers, and how strong their powers are (and whether management will refuse to get rid of them, etc).

    No one who’s worked on software projects over time can have missed the spectacular power of such people to wreak destruction.

  33. ‘Super-programmer teams have been tried and have shown no compelling benefits’ – except the legendary small teams used by Steve Jobs to produce some very successful software.

  34. @blizzard Do you have any references to the structure of the software teams at Apple? I think you’re probably referring to the control that Jobs himself exercised. While he was undoubtedly a master of product design, he didn’t write production code.

Comments are closed.