Three myths about developer effectiveness

Bill Taylor has an article on HBR that introduces some very misleading ideas about developer effectiveness, which I’d like to address. Here I set out some reasons why excellent developers are actually disproportionately more effective than average developers, despite what Bill might lead us to think.

Software isn't like football, as it happens - Photo by Nik SilverHere’s his starting point:

Last month, in an article in the New York Times on the ever-escalating “war for talent” in Silicon Valley, Facebook CEO Mark Zuckerberg made a passing comment that has become the entrepreneurial equivalent of a verbal tick — something that’s said all the time, almost without thinking.

“Someone who is exceptional in their role is not just a little better than someone who is pretty good,” he argued when asked why he was willing to pay $47 million to acquire FriendFeed, a price that translated to about $4 million per employee. “They are 100 times better.”

At first blush that does indeed sound like an awful lot of money. Bill goes on to draw comparisons with (and evidence from) football, ice hockey, and top performing Wall Street analysts. He concludes that environment or situation is also highly significant, and that great developers’ worth is significantly overstated. Undoubtedly environment does play a part, but his central claim remains that Silicon Valley employers are vastly overestimating the value of great developers, pointing to that Mark Zuckerberg quote and also to Marc Andreessen (“Five great programmers can completely outperform 1,000 mediocre programmers”).

He then hammers home his position with these stark rhetorical questions:

If you are building a company, would you prefer one standout person over one hundred pretty good people?

If you were launching a technology or developing a product, would you rather have five great engineers rather than 1,000 average engineers?

Hahahaha! Crazy! Who in their right mind would… hang on a minute. I know several really smart, digital people, with proven track records, who would have that preference. Hell, even I’d make that choice a lot of the time, and I wear a suit. I’d do that because I’ve had experience of working with such people: greater skill in software development really does pay off disproportionately.

By way of objective explanation, let me try to bust three myths which are probably held by the sceptics, even if unconsciously…

Myth 1: Writing software has a one-time effect

False. This is not like football. Scoring a goal has one-time effect — you score, your team win a point, and that’s that. Hopefully your team can build on that success, but the goal has no more impact beyond the moment at which it is scored.

By contrast, software has a lifespan than only just begins when it is written, and only ends when it is switched off or deleted. This means well-written software has a positive impact that continues: others understand it, can work with it more easily, and so it makes their work quicker and more reliable. Poorly written software is opaque, other developers avoid it and work round it due to fear or confusion; the system becomes more complicated, less reliable, more difficult to change and negatively impacts those who use it.

A better developer will more consistently write software better, which means the benefits multiply.

McKinsey's 2001 War for Talent paperMyth 2: Writing software may be creating, but it’s not creative

Undoubtedly writing software is creating something, but it is also creative in that it benefits greatly if the developer has imagination and intuition.

Consider the lower levels: with modern tools and frameworks there are myriad ways to tackle the same problem. A really great developer will make creative leaps, or introduce new ideas, that evade others and bring simplicity and elegance never previously imagined. The result? Faster delivery, greater flexibility, more reliability — effects that (as discussed above) ripple far beyond the initial point of delivery.

And consider the higher levels: a really engaged developer will see new opportunities — for features or entire lines of business — because they see links and alignments between the system and other technologies that just aren’t visible to others.

Myths 3: Developers are there to do what you tell them

“Do this thing this way” will probably get you want you think you want, and will almost certainly not get you what you really want.

Good developers will work with you to find out what you really want. They will quiz you on your real motivations, and ask “why?” a lot. And what will often happen is that they end up doing something utterly different to what you originally anticipated, which allows you to do what you want more directly and more completely. Sometimes it requires writing no software at all, and simply pointing you in the direction of something that already exists. This is someone who has leapt beyond “doing the thing right” and is addressing the issue of “doing the right thing”.

By making these myths explicit I hope I’ve shown that stronger developer produces disproportionately greater benefit than one who is not so strong.

Some truths remain

Of course there are some truths in Bill Taylor’s article, but I don’t think they’re at all controversial. Yes, of course some developers are overrated (and some are underrated). Yes, of course there is more to long term performance than individual excellence. Yes, of course situation impacts performance. Yes, of course your colleagues influence your effectiveness.

And maybe Mark Zuckerberg paid too much for FriendFeed. But maybe not that much more. His “100 times better” comment should not be taken literally — it’s a rhetorical flourish for the media, not a formula in a spreadsheet. If he’s paying $4m per employee then it’s not a 100x valuation on each: there were 12 employees, and we can guess they were each earning  $80k to $100k, which makes that a 50x valuation on each individual. Reduce it further by recognising that he’s bought the whole team, which (we have acknowledged) does influence each individual’s effectiveness. Reduce it further by any number of other factors: scarcity, preventing them going to a competitor or impacting Facebook, money to outside investors, and so on. I reckon that’s roughly a 20-30x valuation on each individual. Maybe a bit high, maybe not, but far from the flashy “100 times” claim, while still recognising that great developers are disproportionately more effective than less great ones.

There are a couple of other truths to mention, too.

One is that, of course, sometimes you’re dealing with something really, really big — when it just won’t be delivered with five engineers (however outstanding) and you do need nearer 1,000. The other is that “five great engineers [or] 1,000 average engineers” is a false dichotomy. Mark Zuckerberg understands that, too: you can expect him to have 1,000 great ones.

18 thoughts on “Three myths about developer effectiveness

  1. Yeah. As I posted as a comment to Bill Taylor’s article: people can only see intelligence up to their own level. For levels of intelligence above that point, they have no frame of reference. Then they go and write articles like that one. I don’t think it’s anything to fret about: just go and work for someone else…

  2. Nice points!
    I could argue against the one-time effect of the football analogy, since a score HAS a lifespan going beyond the single match if you’re team is playing any kind of campionship, but not against Myth 2: creativity definitely helps, even when writing code.

  3. What most programmers are missing to be great , is the business insight to put themselves in the end users seat and visualize what is really neeeded to make the task easier. I would say the benchmark for the 1 guy who does the work of 100 is an “Application Analyst” just like the old “Systems Analyst” who would spend a week or a month watching how a business worked before designing a system and Software for a Company. Today most Programmers have done nothing else but code so they have no clue how to create a good program for use in the real world.

  4. Maybe this has already been brought up but back in the 60’s IBm used to champion the “Chief Programmer” concept where one highly productive individual was surrounded by a bunch of support staff. SO they could spend their time doing what they do best. So I think Zuckerburg is right.

  5. For many years I have used the following definition:

    software engineering: n. The act of convincing a computer to do impossible things.

    Creative, vocal developers are crucial in this process. Thinking the same old way will never get you there.

  6. You guys do realize that Mark Zuckerberg is not a business expert, or even an IT expert, right? He occasionally stumbles on a good point, but lets not hold him up as some kind of businessman – he’s a guy who got lucky. Let’s not put too much importance on that.

  7. I think you really hit the nail on the head with myth 2, of all the exceptionally talented developers I know out there, they are all very creative, almost to to the point of having an extra artistic dimension in their work.

  8. @Davide Orlando – Yes, I really struggled trying to explain what I meant about results in football, and I’m still not sure I got it right. To try again: effectiveness in football is additive, while effectiveness is software is multiplicative. Hmmm, still not happy with that. This means either I need to work harder on it, or I’m just wrong about that.

    @Jasmine – I do believe Mark Zuckerberg got lucky, but I also believe you make your own luck. Not everything he does is right or will lead to success, but I’d say he’s had enough success in tech that his ideas in that area are worth listening to.

  9. A good article and very truthful. I.T. has never really become a ‘profession’ like real professions. A doctor, or lawyer, gets crediability for their skills. So far at least I.T. has failed to become a recognised and true profession. The fault has to lay with the industry itself and nobody else.

    FriendFeed may have involved patents also, and that will be where the real money lies. The great people in the staff have probably been underrated by everyone when pricing the asset.

  10. Let’s see if I have this right, people that solve problems are better at solving problems than people that don’t solve problems. Corollary, people that right drivle blog posts are better at writing drivle blog posts than people that don’t write drivle blog posts. Thanks for the insight. Not.

  11. I’am pretty sure we don’t speak about the same things. Bill Taylor is likely to think about the average company, producing average product. It may be even just a company that has contracts for producing some program or doing some IT.

    Or the thing is, in IT, you have easy money, but you don’t gain much. You agree that a beginner is paid maybe 500$ an hour, and very talentuous and experimented guy 1500$ an hour.

    You may negociate to make a software for a total amount of xyz$ counting the cost per day of your teammate and estimating how man day you finally need to do the job.

    This is low risk, low reward business. It pay well, but that’s all.

    Do you care about make wonderfull software? No you want to get the job done. Do you want to think of easier ways or differents way to do the job? Not really typically technology and all are in the contract, nothing can’t be changed.

    Do you care that your final product is good? Not really. You don’t want to be out of business so you ensure that you product are good enough. But making particulary great product instead of good enough may increase your revenues a little. No more.

    So yes you don’t care about outstanding people. You just do an easy, time consuming easy job under contract.

    Now imagine that you are a software editor. This is totally different. Cost of making is huge, but you can sell nearlly unlimited copy of it. When making your software, scalability is infinite and at no cost.

    You can choose the technologies, you can choose the way you solve problems. What is important is that it works, and works great.

    That’s why you care about having the best ones. Because you know they are maybe just a little more effective to do the exact same thing (well maybe 10 time), but more importantly, they will be able to do thing that other simply can’t. And that what make you sucessfull.

    That what apple, MS, facebook or google managed to do. And they are there because of the talented people. But this is not the same business as the average IT shop.

    An IT shop can maybe manage to get a 10X increase by hiring wonderfull developpers. Maybe. More likely the company administration and processes will restrict them to 1,5X or 2X. But that’s all. Not really interresting.

    A sofware editor by using them accordingly can make 100x, 1000x, 1 000 000x more money. Here that’s something.

  12. @Ed Wisniowski, @Nicolas – I absolutely agree that sometimes “good enough” is good enough. Not every piece of code is intended to change the world. That’s why I was careful to say I’d make the choice a lot of the time, with the implication being that I wouldn’t make the choice all of the time. And there is much more to say on that.

    To roll it all up, I’d say better skills in development makes someone disproportionately more effective, but that doesn’t mean they’re right for your project/business, or that their value to you is the same as the value they are to someone else.

  13. Nice post. I agree – good developers not only do things quicker, they do things better and with less code and with a lot of neat re-usable stuff for the next task to boot. They are strategic. Then the next task they do, they draw on what they already have and do it even quicker. They learn from prior mistakes and get the basics right. I have had endless experience working with developers that just don’t get dates, nulls, left joins and other bread and butter fundamentals. They make the same mistakes, year-in year-out on the SIMPLE stuff. Wow!

    When you do stumble across a bad developer containment is a good strategy. Give them something technically very difficult to do, but of non-critical importance. Then keep sending them bug reports so you can limit the immense damage they will do if set loose onto other things.

  14. Zuckerburg isn’t paying for employees, he is paying for customers/users and to a lesser extent code.

    First mover advantage means that Facebook has taken the niche for usable social media (MySpace was not usable, and LinkedIn is supposedly for business social media)

    Bill Gates was not the best programmer in the world, he was another Harvard drop-out (read rich, smart kid) who got serious Establishment support very early on for his start-up and could afford to buy success by buying talent

    If talent was so important, why have venture capitalists at all? in fact, with cloud computing VC are struggling for relevance

    the star system in the US is unquestioned, every aspect of life is winner takes all, which ultimately is unsustainable, it leads to a fragile and concentrated ecosystem

    Silicon Valley VC need to spend money (capital dies if it doesn’t move), and pump and dump happens all the time.

    How many second tier dot com “serial entreprenuers” do you see who have resumes full of start-ups that got bought out that no longer exist?

    stars are great for new directions and inventions, but one person cannot build a Facebook

  15. I don’t think anyone is 100 or 1000 times “better” than someone else simply at writing code. Clearly some coders are better and/or faster than others. This is inarguable.
    However, it seems likely to me that the real differentiators can be found at a somewhat higher level. Namely not just “how” the code does it, but “what” it does. Yes there is variability in the “how” as well, and this too can spell the difference between success and failure. But the big leaps are in the “what” not the “how”. I tend to agree generally with commenter Bigus above.

  16. There is a lot of truth in the idea, but a good portion it the vision and willingness of a company to allow the talented to perform. Many large companies are so full of beurocracy and methodoligy that star performers are squashed. We have seen a situation where one creative analyst with a couple of programmers built a system that is far more stable and useable than the corporate group of dozen of programmers onshore and offshore, project managers, etc. built. The creative developer who can understand the business and what a users needs is far more valuable that a roomfull of programmers that deliver what the user ‘wants’. This is also why offshoring is an unsustanable trend. As more powerfull development tools are placed in the hands of skilled business analysts, the ‘factory’ mode of development will fade away since it is just too slow/ineffective, replaced by agile fast development. Companies pursuing offshoring as a ‘cost savings’ mode will be left behind by talented agile companies delivering value to the customer.

Comments are closed.