Hacker News Reader

Comment by ExpiredLink | Hacker News Reader

The '10x' super star and other myths debunked:

The 10X productivity thing may be a myth. What I've seen in 35+ years programming is developers fall into three broad categories:

1. Can't get anything done on schedule or in budget. 2. May eventually get something done, late and over budget. 3. Delivers what the customer needs on time and within budget.

The first two groups just cost the customer time and money, create uncertainty and stress for the customer, and may or may not deliver something of value. A better developer doesn't have to be 10x better (however that is measured). They only have to deliver what the customer needs within the time and budget parameters.

From the customer's point of view the relevant scale is not 1 - 5 - 10 times productivity from the developer. The relevant scale is 0 - 1, where anything much less than 1 means their business problems weren't addressed in a useful way. It doesn't really matter that one programmer had 10x more commits on GitHub than another programmer if the customer can't ship packages because the programmer didn't correctly add shipping charges to the invoice (real example).

Anyone who is freelancing, leading a project or team, or calling themselves a ninja, rockstar, wizard, etc. should not be surprised or indignant that customers don't understand their requirements and usually can't communicate their needs in a complete and consistent format. That problem has been known since the 1950s. Blaming the customer is not an option. An effective developer will concentrate on business needs, ask the questions and get the answers, and work with the customer to nail down requirements.

When I get involved with a broken/stalled project the first thing I do is ask the customer to make a short list of the problems and missing features in decreasing priority order. What I always get, without exception, are business requirements, not technical glitches. The root cause of a missing business requirement may be technical (e.g. failed PCI compliance audit because of vulnerable PHP code), but all the customer cares about is the business requirement. It doesn't matter if I am 10x faster or smarter than whomever was working on the code before as long as I can fix the problem.

>...developers fall into three broad categories: 1. Can't get anything done on schedule or in budget. 2. May eventually get something done, late and over budget. 3. Delivers what the customer needs on time and within budget.

And since software estimates is a known hard problem[1], the only different between 2 and 3 is often just the fact that 3 has learned to appropriately inflate his/her estimates.

I say that as someone who has oscillated between 2 and 3 over my career, although the trend over time is toward 3.

1. https://news.ycombinator.com/item?id=6820547

I was making a distinction between the customer's schedule and budget and the developer's estimates.

If your customer (or employer) has no schedule or budget, great, you've landed a job at the next cool startup.

For every other business that is paying for software development the value of the software usually has budget and time constraints. When a customer/employer asks developers for an estimate they are either asking for a commitment to deliver within time/budget constraints, or starting a negotiation where features are changed or removed, or "resources" (more developers) are added.

You are right that it's very hard to get estimates right -- one of the biggest unsolved problems in software development, and one that has been known and written about for decades.

For the jobs I take on, I ask the customer to break down the work into a list of bugs or missing features or missed requirements. Then I ask the customer to put the list in priority order and assign a dollar value and schedule. Then I determine if I believe I can commit to addressing the list, item by item, within their cost/schedule constraints. If I don't think so I tell the customer, and they either change their requirements and constraints, or they go look for someone else -- I don't charge for determining if I can commit or not.

You can do this in terms of a MVP (minimum viable product). If my customer has nothing -- green fields development -- another way to look at that is none of their requirements have been met. So let's put those requirements in priority order and assign maximum costs and schedule to them. I've never been entirely successful at getting customers to actually do this for new development (one reason I rarely take on green fields projects anymore), but when I have tried it they have generated requirements with costs and times that are at least as realistic than any estimate I might attempt.

I think this is an excellent approach. The only problem is finding clients that are both capable and willing to sit down and hammer out this type of informal spec.

The debate about whether the 10x developer exists or not is based on a misunderstanding in my opinion.

To prove whether there exists a developer that is ten times as productive as an average developer, you would probably have a hard time both figuring out how productive an average developer actually is, producing a good measurement for productivity, and finding that unicorn. I'm not going to say it's completely unthinkable, there may be a few unicorns out there. Or there may not. In any case, you probably aren't going to find one. Save your money.

However, the statement isn't usually that there is a "10x average developer", the statement is that there exists a developer that has 10x the productivity of another developer. This isn't a myth, and it's not even controversial! Anyone can call themselves a developers, and there is obviously no lower bound in productivity! Ergo: you should quite easily be able to find a developer with 1/10 the productivity of an average developer, and the "myth" of the ten fold difference in productivity is confirmed right there.

From the article:

    ..."well-known fact" of 10x variations in software developers

vs.

    There is a hidden inference at work: "there exist programmers 
    who are ten times as productive as the average"...

The former does not imply the latter. If "10x variation" would mean there is a 10x average, then surely the variation must be much larger if you consider the 1/10x average dev?

When it comes to programmer productivity, just try to look for solid developers. There are those that are surely twice as productive as others. Maybe three times. So pay them more. Or get two regular ones. Just avoid the 1/10 developer and you'll be fine. Not least because the 2x developers will likely quit if they are put in a team with the 1/10!

I came in on a project where an outsourced team of two had spent 6 months developing this little app. It was a mess, took over s minute to load, shipped half if Windows as dependencies, and didn't really work. In one week, I had a more functional version working, and with less than a month of further work, we had a finished product. So, that's a 50x difference, at s minimum.

Same on a small scale. Little feature needed adding to a tiny codebase (no hidden enterprise or framework stuff). One guy said he could do it in an hour or two, I took under 3 minutes. Sure, maybe he just failed to see the obvious, easy, FP, way and planned to build some huge OO system. Still, the overall result remains.

I dunno if these other people were average. But I am shocked at the lower levels of competency available and actively working and billing people.

Edit: And I know I'm nowhere near top coder level. I've a limited understanding of many things. So much stuff I read of other people's work impresses my greatly and leaves me knowing I'll never be top level. I don't have a one-in-a-thousand IQ. I find it very plausible there are people 10x me, and I'm probably above average.

> 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

http://www.knowing.net/index.php/2011/12/09/forbes-is-wrong-...

> The Myth of the Rockstar Programmer

http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer...

Depends on the suitation when I worled for BT another devloper and I developed in a month in a RAD/DSDM web project project what another part of the biz had quoted 2 years to develop.

But we did have a depty CEO (Bruce Bond) as a sponsor so stuff got done quickly.

I reccon in my entire period working at BT that month was most prodcutive - and thats including the time I spent a coupel of days sorting out a BACS trasfer that netted 3/4 mill.

> Fact and folklore in software engineering

http://morendil.github.io/folklore.html

> 10x Engineer

http://web.archive.org/web/20131110050028/https://medium.com...

Every place I've worked at, there have been obvious examples of the one guy that management would sacrifice 2-3 other people in order to keep.

I find I personally can be 10x more or less productive depending how many interruptions, meetings and simultaneous projects I have to manage.

Reply on news.ycombinator.com