The Leprechauns of Software Engineering

Over nine thousaaaaand times more productive!

Vegeta, what does Nathan Myhrvold say about the productivity differential between top software developers and average ones?

Nathan Myhrvold, it turns out, says: ”I was speaking colloquially when I said “10,000X” - it is not meant to be an utterly precise measurement.”

But hey, “the general effect has been verified in a bunch of studies.”

It’s worth noting that the Myhrvold claim is a double mutation of the original “10x meme”. The most obvious mutation here is that 10x gains three orders of magnitude.

But an even more deleterious mutation is the one from “difference between best and worst developer”, to “difference between best and average developer”.

Knowing how Internet memes work, I wonder if someone will take it one step further and claim something more outrageous as being backed by “a bunch of studies”… In fact I wonder if it has already happened…

To succeed in the software industry as it turns into something more like a never-ending live jam, we have to learn to put away our egos, work successfully with others, worry less about our own skills and look more at others, put away our natural insolence and attitude, and to learn to like and trust other people.

Does this mean we need a license to code? Should software only be developed by the wise sages locked away in the towers on the hilltops? I don’t think so, but it’s frightening to see the amount of fluff and hubris fueling large projects that affect our health, economy, and daily lives.

During several of the sessions at ICSE I was struck by a strange, uncomfortable feeling which I subsequently identified as a consequence of having a feminist moment (if you’ll allow the conceit).

Many [speakers] spoke earnestly about these people called “practitioners” but spoke of them in a way which suggested that (1) there couldn’t possibly be any of these people in the room and (2) they are other, a strange and mysterious group with peculiar motivations and interests who need to be studied, and handled, carefully and (3) they need someone strong and capable to come and help them out—all in their own best interests, of course. […]

It took a while to realise that they meant me.

(An interesting illustration from Keith Braithwaite of the research-practitioner gap.)

Are you interested in software engineering, in how we educate our future engineers, and in how we can bring some real intellectual rigor to the software engineering profession? Give Bossavit’s book a try; I don’t think you’ll regret it.

As I think I’ve pointed out here before, the actual contribution of a research paper is often different from the claimed contribution. Or, to put it another way, we first need to understand what the authors intended to say (often this is not easy) and then we also need to understand what was left unsaid. A subtle reading of a paper may require a lot of background work, including reading books and papers that were not cited in the original.

My kids often come home from school spouting crazy “facts” they’ve learned from classmates. It seems fundamentally human to repeat stories and, in the repeating, alter them—often unintentionally. Researchers do the same thing, and just this morning I was irritated to read an entirely inaccurate citation of one of my own papers. No doubt others have had similar feelings while reading my work.

An old friend

I met an old friend earlier this week.

This acquaintance goes under many names, and many faces. This time the manifestation was: “Yes, but just because you can’t find hard data that backs up the claim, doesn’t mean the claim is _false_.” The claim in question was the venerable “law” according to which “the cost to fix defects rises exponentially the later you find them”.