The 10x engineer exist but not because he or she is so great but because they wrote the shitty code in the first place so it takes a new person 10x longer than the author to do anything.<p>the exponential cost thing is probably somewhat true. If the people who come up with the software actually knew what the fuck they wanted they would save the software from having to guess wrong and redo the code. Unless the software runs on a million dollar jet or something finding a bug during testing should not be 100x more then finding it during code. Infact I can make a decent argument that it is cheaper to pay a tester to find bugs then to waste an engineers time looking for them.<p>the software crises story about defence i think is real: <a href="http://www.reuters.com/investigates/pentagon/#article/part1" rel="nofollow">http://www.reuters.com/investigates/pentagon/#article/part1</a>
I've been a fan of Laurent's work in this area for a long time.<p>What I find most interesting is that Laurent's work is <i>clearly</i> about the pervasiveness of myth and the need to apply rigorous thinking to what we believe. It's not about the specific claims; those are (fascinating) examples.<p>And yet, every time, people get <i>really worked up</i> about the 10x issue. They ignore the broader point entirely and focus on that one claim. (I find it particularly interesting that they focus on 10x and not any of the other claims Laurent debunks. Perhaps because it's easily understood? Perhaps because it's easy to think of anecdotes? Perhaps—and I suspect this is the real truth—because they secretly believe in their hearts that they're among the Chosen, and Laurent's threatening their clubhouse?)<p>Laurent doesn't say, "there are no 10x programmers." He says, "the studies that claim 10x programmers are so weak as to be laughable, the notion of measuring productivity itself is controversial and poorly defined, and do you even know which ratio you're using when you say 10x, anyway?" (He's not quite so informal about it, but that's the gist.)<p>In other words, the 10x claim has yet to be <i>defined</i>, let alone subject to rigorous analysis.<p>But out of the woodwork come these people who say, "I've seen 10x, therefore it must be true!" (I can't help but believe that these are the same people who jump up and down saying "the plural of anecdote is not data.") To be blunt: irrelevant. Laurent didn't say "there are no 10x programmers." Sit down already. Read it again.<p>You know what? The 10x claim doesn't matter. Laurent's not even saying it matters. His argument is bigger, more interesting, and more valuable than that.<p>He's saying that people—us programmers, specifically, who so wish ourselves to be rational thinkers—believe things because we <i>want</i> them to be true. Not because of the "evidence" and "proof" we're so keen to demand when we hear something we <i>don't</i> like... but because they're the myths that surround us, and they make us feel good.<p>(And now I hope morendil will chime in and tell me how I've misinterpreted him. ;-) )
The biggest problems is that no "law" or "rule of thumb" of software engineering is always right. So "debunking" by finding an exception isn't really useful. The best answer to most of these questions is: It Depends (tm). There are situations where the right person making the right calls makes a huge difference and there situations where anyone can make a call that would turn out reasonably OK. There are situations where buggy software has little impact on the business and there are situations where it can result in bankruptcy. This is partly why this is difficult to research in any sort of rigorous fashion and why we should definitely maintain some degree of scepticism to any broad claims.<p>x10. Anyone here do the TopCoder Algorithm SRMs? There's clear evidence of x10-ish performance difference between the "red" coders and the average coders in there. Does that always apply? No. In certain situations can certain developers blow the average away? Absolutely yes. This is true for things other than software development.<p>The author talks about "engineers of equal experience". No such thing. There are no two single developers with "equal" experience.<p>Bug fixes. It's a no-brainer to see the cost of fixing an issue by the same dev in reasonable proximity to when the code was written is a lot cheaper than someone else fixing that bug 6 months later. It's also a no-brainer to see that the cost of fixing a bug in nuclear reactor control software that can cause a core meltdown is cheaper before the core actually melts down. In between there is a lot of grey area but I think there's a lot that can be applied while still being safely in the no-brainer region, that is our intuition, that is our learning/pattern recognition over years of software development.
"The trope of 'software as a highly abstract, intellectually demanding, nearly mathematical activity' contributes to a myth of software development as a profession 'naturally' dominated by males: math is the subject of its own interlocking system of tropes, myths and stereotypes that paint it as a manly pursuit."<p>That logic seems to be all backwards to me. Of course developing software is a highly abstract, intellectually demanding activity. Claiming it’s not is as absurd as claiming women are somehow incapable of doing exactly that.
Can anyone name a finding of software engineering research that isn't folklore? I've looked many times. The field is strikingly weak. It is typified by tiny sample sizes, subjective analysis, and zero replication.<p>[Edit: deleted mistaken impression here.]
Software development is a craft driven by heuristics. The conditions for every project are different. It's difficult to identify contributing conditions. These conditions include technologies, abstraction, business factors, trends, development talent, talent of peers, market position, maturity of the market, funding, knowledge of current requirements, mutation of requirements, complexity of the requirements, interacting agents, etc.<p>I can see why it would be so difficult to find correlations.
"The best I can do, therefore, is this: my advice is to open your eyes to the pervasive influence of culture on all the things you deplore; to acquire and use whatever tools, from semiotics or literary criticism or whatever, seem to be handy in understanding the water of myth around you.<p>And when you get there: write about it (or sing, or make movies). This, really, is the key thing. Not only do we need to talk more, not less, about how we develop software, we also need to talk about the things we say: we need critique."<p>if only the discussion on hacker news would actually take this advice instead of arguing arcane bullshit. Hoping a few will take this tack. Please surprise me.
Well, at least he's doing his best to prove the myth of all programmers being humorless autists who take everything literally to be true...<p>Yes, sure, we're talking about <i>exactly</i> 10x when we talk about 10x programmers. Etcetera, etcetera.<p>Even the most fanatical Agile evangelist gets both the tongue in cheek humor (with a serious undertone) of Zed's "programming, motherfucker", but not this guy.
Tons of 10x hate in here already. Is there a reason this is such a stumbling block for people? Is there a reason that isn't tinged by sour grapes? I'm like 99% convinced that I've worked with such people and seen what they can do. I'd be willing to buy that it isn't simply the individual, but the individual plus the right circumstances. But I absolutely can't say that I've never seen a single developer write a surprisingly large amount of good code in a surprisingly short amount of time, because I have seen it.