The origins of the 10x developer
By: Jeff Foster
Tags: Software Engineering, Productivity, Software Development

For as long as I’ve been in software, there’s been talk of the 10x developer. These are the people you want to solve your problems; they’ll do it in 1/10th of the time, with 1/10th of the number of lines of code. They sound awesome.

But were did the term come from? Do they exist? And even if they do, would you want to be one anyway?

Coding War Games

Tom DeMarco and Tim Lister have, since 1977, conducted the “Coding War Games”. This is a public productivity survey in which teams of software implementors from different organizations compete to complete a series of benchmarks in minimal time with minimal defects. They’ve had over 600 developers participate.

What did they learn?

Choice of programming language had little impact — whether it was COBOL/Fortran or a high-level language like Pascal the spread of results is about the same. The only exception was assembly language.

There was no correlation between experience and performance except that those with less than six months of experience with a language did not do as well as the others.

that those with less than six months of experience with a language did not do as well as the others. The developers of zero-defect solutions paid no performance penalty for doing more precise work (in fact, they took slightly less time!).

They did find that there were huge differences between the organizations. The best organization worked 11.1 times faster than the worst. In addition, those that worked fastest developed code that passed the acceptance test. Case closed?

Well, not quite. The study then goes on to correlate the workplace environment (which is different across organization) to performance. It turns out that quiet, private, dedicated working space group performed significantly better.

Environments for coding

Lesson learnt — get your working environment right first before you start to worry about whether you can find 10x developers or not!

The Net Negative Producing Programmer

Schulmeyer observes that some developers are “net negative producing programmers” (NNPP), that is they produce so many defects that removing them from the team increases productivity. This almost the opposite of the 10x developer — it’s possible to have someone on the team that makes it worse.

If negative producers exist (- Nx developers?) then it’s clearly possible to have a 10x developer (mathematics aside).

It’s not the greatest argument for the 10x programmer though, is it? If I asked a school child to join a team, would they be a net-negative producer? Probably, if I let them sit in a corner and bash in some code (and if some how they can push to production!). If you’re the sort of company that lets people sit in the corner, doesn’t give feedback and lets them push to production then I think you probably deserve to have NNPPs on your team!

More realistically, I hope that in any normal company if you employ someone, you’re going to give them all the support they need to be awesome in their role (peer code-review, feedback, a mentor, automated code analysis for feedback, learning materials etc.)

I guess it’s still possible that you could end up with an NNPP but I suspect it’s highly unlikely. This certainly doesn’t seem to be the best story for the existence of 10x developers.

Exploratory experimental studies comparing online and offline programming performance

Sackman, Erikson, Grant published a paper in 1968 called “Exploratory experimental studies comparing online and offline programming performance”. One of the quotes at the end is around individual differences and the studies “revealed large individual differences between high and low performance, often by an order of magnitude”. Could this be the magic paper that describes that 10x difference?

It pays to read the whole study and put some context around this. Firstly, these tests were comparing both pen and paper performance as well as online using an IBM AN/FSQ-32. Programmers wrote their code (either on pen/paper to give to an operator, or directly into the computer) using a language called JTS (an ALGOL derivate).

They had two tasks to solve, the first one was to interpret algebraic equations with a single dependent variable. They were given the paper by Samelson and Bauer to help implement the solution. An image from the paper is shown below:

Obvious, right?

The second task was to solve a 20x20 maze which has exactly one path. The maze was described by a 400-element lookup table where each entry contained information of the exits of each cell. No supporting material was provided for this challenge. Maze solving is a fascinating problem space and I’d guess those you had completed a graph theory course recently had a big advantage!

Knowing these tasks, I’m not surprised there is large individual differences. In 1968, software engineering was only just born as a discipline. The tasks are mathematical in nature and it’s not clear what the background of participants were. It’d certainly favour those who took higher-level mathematics courses.

I think the 10x person you’d find from this is gifted at solving these problems. I can believe that in the problem space of “solving a maze + linear equations” there can be a 10x developer, but it’s difficult that this would transfer to any other domain.

Should I be a 10x developer?

Probably. But probably 10x better at writing code.

There’s a much better discussion of the research methodologies behind the 10x developer myth in this excellent book. Even if a 10x developer exists, you probably shouldn’t aspire to be one; even if you can implement code perfectly first time, you’ll probably find you were solving the wrong problem in the first place.

Even if those studies were true, software engineering has moved on (at least in my domain of product development).

In the old days, we might do a single big release a year, have some requirements and spend the year implementing them. This has changed to an agile approach where there’s a continual cycle of eliciting, imagining, implementing and verifying. In this model, implementation isn’t (usually) the bottleneck

An hour saved at the non-bottleneck is a mirage. (Eliyahu Goldratt)

So what should you do instead? Well, focus on being more valuable to your business. Can you:

Identify valuable problems for your business?

Design a solution that people can use?

Gather feedback to assess whether it’s valuable?

Write software that makes a real difference to real people?

Focus on the real problems rather than the interesting?

Grow members on the team to be awesome?

And a million and one things that are more valuable than writing perfect code in record time (see t-shaped!).

This is not to say that coding isn’t important. Coding is important! Code is read 4x more than it’s written, so if you write easy to reason about code then it pays off dramatically in the future (maybe there’s a 10x story in there somewhere, but I’ll leave that for another day). Investing time in your craft (be it coding or design or project management) is a must, but just remember that your craft doesn’t exist in isolation and exists to serve a higher-goal.

Don’t just focus on being the best-ist developer in the world, focus on the bigger picture (remember Product over Project!). Learn a broad set of skills (especially those people related ones) and you’ll be much more valuable and much closer to a true 10x “developer”.