Human Performance CurvePosted: June 1, 2011
In writing the last blog on motivation my mind was drawn repeatedly to thoughts about performance. After all, motivational techniques are primarily about boosting performance. But as I put “pen to paper” for this blog it turned out harder to write than I expected. Human performance is a squiggy topic but unquestionably important.
I start out with some classic performance curves that apply to factories, motors and other mechanical systems. Next I move to the human performance curve and then consider the large variability of the performance of programmers, the Elo rating system for rating chess players and musing on its relevance to programming. I close with sage advice to programmers from Captain Barbossa and Dirty Harry (who, as far I know, are not fictional programmers).
Mechanical Performance Curves
Consider a factory that manufactures “widgets” — the term used by economists for some generic manufactured object. Perhaps it is a Ford Model T, or an Apple iThing, or whatever.
Let’s start out with the factory producing a low 100 widgets per day. The staff and machine are mostly idle. The factory is under-utilized and the economic value is low.
Let’s ramp up production to 500 units per day. Production is getting more efficient with better utilization of staff and equipment. We’re still well within capacity so errors remain low and quality is high.
Now let’s double production to 1,000 units per day. We’ve reached optimal performance. We’re at the point where staff and equipment are just within their capacity with errors remaining low and quality high. But only just because some parts of the system are close to performance problems.
Now if we push a bit harder problems begin to creep in: equipment jams, people start to make more mistakes, rising stress leads to longer term problems, and so on. Not all parts of the system are exhibiting problems but local issues start to cause systemic failures. Because the system is at its limits it also becomes harder to recover from problems.
From here, the harder we push the factory the worse the overall performance will become. The degradation in performance may be gradual or could drop precipitously.
Thus, we have a typical factory performance curve.
Factory Performance Curve
The performance curve is not immutable. Innovation drives improvement through change in process, development of better equipment, training of staff, creating better working environments and so on.
Many systems share a similar performance curve to the one shown above. For example, here is an example of real-world performance curves for a motor. The performance measured both as torque (rotational force) and power output (as horsepower) each for increasing revolutions per minute.
Performance Curve – Motor 2
Human Performance Curve
Though nowhere as easy to quantify as the performance of engines or factories, people have performance curves that look similar. Here’s a typical performance curve which, I think, applies reasonably well to programmers.
Human Performance Curve
Pacing yourself is about spending most of your time in the effective zone and occasionally pushing into the optimum zone.
There’s not much point in pushing yourself or others beyond peak performance because output suffers, errors rise and stress builds. But it is surprising how often people will push past peak and keep trying harder to break through exhaustion.
But human performance is highly malleable and variable. Let’s consider just a few variations.
As discussed in the last blog, effective motivation (intrinsic or extrinsic motivation) boosts the performance curve. Motivation might be the joy of working on an interesting problem, the desire to meet a deadline, a desire to avoid failure, looking good to peers, looking after a customer or a (well-considered) financial incentive.
Working within your competence or at its limits results in higher performance than either working on trivial/boring tasks or working beyond your capability.
Working in The Zone is all about working at optimum performance. It is the combination of a challenging task, confidence that you can tackle it, knowing the direction you will take to achieve it, and working in a good environment.
Conversely, exhaustion, intense stress, fear of failure, lack of direction, and many other factors can squash performance.
Elo Ratings and Chess
I’ve often heard people comment that the difference in productivity between a good programmer and a very good one is a factor of ten. I agree based on my experience, though I would like to see empirical evidence that supports or refutes this claim. (And I’ve never seen top programmers paid ten times the average salary of a team!)
So in the absence of data that I can point to, I will indulge in some speculation.
I think the Elo Rating system used for ranking chess players is instructive about the variation in performance of programmers.
A selective summary for non-chess players (like myself).
- Elo ratings are named after the creator Arpad Elo a Hungarian-born, US-based physics professor and chess master. (So “Elo” is not an abbreviation.)
- A rating is not an absolute measure but instead relative to other players
- A difference of 200 chess rating points between two players means the stronger player is expected to win roughly 3 out of 4 games played (a draw is considered a half-win half-loss).
- A rating is an estimation of player strength. There is variability in strength from game to game and the variability is assumed to be roughly normal (i.e. the classic Bell curve).
- The probability that player A with rating RA is expected to win over player B with rating RB is given by this formula:
The logistic function curve means that the chance of winning quickly drops against stronger players. The table below shows the chance of an average Player A with a rating of 1,100 against progressively tougher opponents.
The chance of beating a grandmaster is theoretically 1 in 10,000 (though I suspect that other factors would kick in and worsen the odds).
|Player B||Rating B||Chance of Player A Winning|
|USCF Class C||1,500||9.09%|
|USCF Class A||1,900||0.99%|
|International Grand Master||2,700||0.01%|
Aficionados will recognise that there’s much more to chess rating that I’ve summarized above but I don’t think the details are important to the following.
Elo Ratings and Programming
Since the introduction of Elo Ratings to chess around 40 years ago, they have been applied to other competitive endeavours such as team sports including backgammon, go, football (soccer to some), American football, basketball, baseball, scrabble, online computer games and more.
In comparison to the sports and games listed above, programming is not normally a directly competitive endeavour so an Elo rating scheme is not easily applicable to normal programming. (How often are two programmers asked to complete identical tasks under controlled conditions?)
However, I think it stands to reason that variability in programmer performance exhibits the extraordinary level of performance difference that the Elo ratings suggest.
The difference between a good beginning programmer, an experienced programmer and the top-flight programmers is likely to be differences of x10 to x100 or perhaps more. In practice I think this means a couple of things.
Given an identical task the stronger programmer is likely to
- Complete the task faster (perhaps much faster or perhaps the weaker programmer will not even be able to complete the task)
- With better performing code (as measured by CPU, memory, bug count etc.)
Shown graphically below, a x10 difference in performance looks as stark as it should (imagine a x100 difference!)
High vs Normal Performance Curves
This is not a call to elitism. Even the best programmers learned their craft starting from nothing. The best environments create opportunities for people to learn, expand their capacity and improve their performance.
I explored the topic of learning in an earlier blog. It is not a linear process. Sometimes we need patience with ourselves and our colleagues.
We should also recognize that the performance of individuals across different types of programming task is not even. You might be great at multi-threaded programming, or database systems, UI implementation, declarative or procedural languages, C/C++/Java/Python/Lisp/VB/whatever, working with tight or loose requirements, individual or team initiatives, high-performance, low-level, or any of so many other types of programming. There are numerous blogs, sites, books, degrees, courses, interest groups and other places in which programmers can improve their performance: in specific areas or generally as a programmer.
Since the section on performance variability and Elo ratings is entirely theoretical let me close with a couple of practical remarks.
- It’s tough to be great at everything. The differences in performance of a programmer across different kinds of programming are innate or acquired through training — most likely it is a combination of both.
- And it’s tough to be at our best every day. Our mood, concentration, motivation and health affect our performance from day to day.
- But it’s also tough not being able to complete a task asked of us. Captain Barbossa of Pirates of the Caribbean has good advice for managers [please excuse the 18th century sexism]
I should not ask any more than what that man can deliver.
- Or as Dirty Harry put it [please excuse the 1970’s sexism]:
A man’s got to know his limitations.
Andrew H – Psygrammer