Doherty Threshold

011 min

Doherty Threshold takeaways

• What it is: Below about a second of response time, finished work per hour rises faster than the time saved predicts.
• Where it comes from: Walter Doherty and Ahrvind Thadhani, IBM, November 1982.
• Apply it by: measuring the delay users actually feel, then aiming sub-second before anything else.
• It backfires when: the step you sped up wasn't the one the user was actually waiting on.

022 min

What the Doherty Threshold actually says

Doherty and Thadhani's report makes one measurable claim: cut a computer's response time — the gap between a person pressing enter and a complete reply appearing — and the number of transactions that person finishes in an hour does not rise in a straight line. It rises faster than the time saved would suggest, and the effect gets stronger once response time drops below about a second.

The report gives a worked table built from the underlying transaction-rate curve:

There is no closed-form equation here, unlike Fitts's Law — Doherty and Thadhani measured real transaction rates across several IBM sites and fit a curve to them, rather than deriving one from a physical model. The report states the pattern in words: "productivity increases in more than direct proportion to a decrease in response time." Going from three seconds to 0.3 seconds — a 90% cut in wait time — more than doubles hourly throughput, a 106% gain.

The mechanism is about what the wait costs the person, not the machine. Doherty had written two years earlier, with Richard P. Kelisky, that people hold a plan for what to do next rather than starting to think only after the reply arrives:

That is the opposite of the belief the 1982 report was written to overturn: that a slow reply was harmless because the user was "thinking about the next task" anyway. If the sequence is already held in working memory, a long pause doesn't give the person more to think about — it makes them lose the thread and rebuild it. This runs opposite to diminishing returns: most gains taper off as you push further, but here each cut below a second returns more, not less, until the curve flattens near the low tenths of a second.

032 min

Where the Doherty Threshold comes from

Walter J. Doherty, of IBM's Thomas J. Watson Research Center, and Ahrvind J. Thadhani, of IBM's General Products Division in San Jose, wrote "The Economic Value of Rapid Response Time" in November 1982. The Computer History Museum's catalogue record for the piece — a 12-page item donated by Bill Worthington — lists it plainly: category "Technical Report," publisher "IBM," 12 pages. It was an internal brief, not a peer-reviewed journal article, a distinction several web summaries get wrong by calling it an IBM Systems Journal paper.

It rests on two earlier, real journal papers by the same pair of researchers. Thadhani had already published the transaction-rate curve on its own, in "Interactive User Productivity," IBM Systems Journal, volume 20, 1981, pages 407–423. And Doherty, with Richard Kelisky, had described the "short-term mental memory buffer" mechanism in "Managing VM/CMS Systems for User Effectiveness," IBM Systems Journal, volume 18, 1979, pages 143–163. The 1982 brief exists to gather that research and a set of internal replications into one document aimed at managers deciding whether to buy a bigger processor.

Before this, the working assumption inside IBM had a name and a face: psychologist Robert B. Miller, at IBM's Poughkeepsie laboratory, had argued that two seconds was the longest a person should tolerably wait, on the theory that the wait doubled as thinking time. Doherty and Thadhani's report exists specifically to overturn that assumption with measured data, not to refine it.

042 min

How the Doherty Threshold shows up in real systems

The clearest documented case is the National Institutes of Health's computing centre. In 1979 its system served up to 300 simultaneous users with 80% of transactions answered in half a second or less, and terminal sessions ran to 32 minutes on average. Demand grew to almost 400 simultaneous users, and computer response time deteriorated to an average of 4 seconds — at which point the average session had grown to 48 minutes, a 50% increase, for the same amount of finished work. Joseph D. Naughton, chief of the NIH Computer Center, calculated that the slowdown was costing the users an extra 22,500 hours at their terminals every month, worth about $900,000, roughly 15 times what a faster processor would have cost. The case is unusual for this literature because the "before" state is fast and well-liked, and the failure is a system that degraded under its own success — a warning as much as an example.

IBM's own programming facility in Portsmouth, England gives the applied case. Terminals there normally shared low-speed lines and averaged 2.3 seconds of response time. For one project, management connected each programmer's terminal over a dedicated high-speed line instead, bringing response time down to 0.84 seconds — not even fully sub-second. The project had been estimated at 30.8 months of programmer time over 19 weeks; it finished four weeks early, using only 18.7 months of programmer time, 39% less than planned. Measured against a comparable project six months earlier, the average programmer produced 14.4 function points a month instead of 9.1 — 58% more output using the same measure of program size and complexity the facility had used for years. Quality assurance then found 3.0 trouble reports per hundred function points on the new project, against 6.9 on the old one — fewer defects, not just faster delivery.

Both cases share the same structure: nobody changed what the programmers were asked to do. Only the time between a command and its answer moved, and the output, the schedule, and the defect count all moved with it.

052 min

A second case

IBM's System Products Division ran a different kind of test: 15 hardware engineers, across 75 work sessions, using high-function graphics terminals to lay out the physical design of boards, cards, and chips — a visual, exploratory task, nothing like a programmer typing commands. Sub-second response benefited everyone, but not equally. An average, experienced engineer working with sub-second response became as productive as an expert had been at slower response, and a novice's output rose to match the average experienced engineer's. The report's own reading is that the expert's advantage had partly been an advantage at absorbing delay, not just at the underlying design work — and that advantage shrank once delay stopped being the bottleneck. A related test, card-wiring exercises run at four IBM laboratories, timed how long engineers took to wire a card as system response time varied. At one lab, task time fell from 82 to 66 minutes — 20% — as response time dropped from 6 seconds to a quarter of a second. At another, it fell from 36 to 23.5 minutes — 35% — over a narrower drop, from 0.6 seconds to 0.25.

The variable that differs from the programmer and NIH cases is the kind of work: engineering design and manual assembly, not text entry or database lookup. A separate test closes that gap. Five component forecasters at IBM's Poughkeepsie facility — an administrative role, maintaining parts inventories and delivery schedules, closer to data entry than to engineering — normally worked with five or more seconds of response time and completed 99 transactions an hour. Given sub-second response for a half-day, the same five people averaged 336 transactions an hour, a 339% increase, the largest gain reported anywhere in the document.

What the contrast teaches: the size of the gain moved with how much of the work was sitting idle waiting on the terminal, not with what kind of work it was. Clerical lookup, engineering graphics, and hand assembly all showed the same shape of curve.

061 min

How the Doherty Threshold changed since

The number that dominates today's articles about this finding — "under 400 milliseconds" — is not in the 1982 report. Its tables test response times of 3.0, 2.0, 1.0, 0.6 and 0.3 seconds; nowhere does the text say "400 milliseconds," and nowhere does it call fast response "addicting."

The wording traces to a 2015 developer blog post. Dave Rupert, describing the report after watching it dramatized on the AMC series Halt and Catch Fire, wrote: "As illustrated by the chart, a sub-400 millisecond response time creates a dramatic increase in users' interactions at all different skill levels. As the TV show dramatizes, under 400ms an activity is addicting, over 400ms it's painful." He credits the framing to the show, not to Doherty and Thadhani's own words — a distinction that gets dropped every time the line is repeated as if IBM wrote it.

The report's real number, sub-second response producing a measured, large productivity gain, has aged better than the specific 400. Google's RAIL performance model, published on web.dev, sets a tighter budget for how modern interfaces should feel: input should get a visible response within 100 milliseconds, a quarter of the figure now attached to Doherty's name. The report's own finding was about mainframe terminals in 1982; the bar for "fast enough" has moved down since, not up.

071 min

Doherty Threshold vs. nearby concepts

The axis that separates all three from Doherty and Thadhani's finding: theirs is the one measured in throughput and dollars, not in what a person notices.

082 min

Applying the Doherty Threshold

Doherty and Thadhani's report was written for people deciding whether to buy a faster processor, and the instruction it supports is narrower than "make everything faster."

1. 1

   Measure the response time the user actually experiences

   , not the server's processing time alone — their own paper splits system response time into computer time and communication time, and a fast back end behind a slow network is still a slow reply.

2. 2

   Treat one second as the point where gains accelerate

   , not 400 milliseconds as a pass/fail line. The report's own data points sit at 3.0, 2.0, 1.0, 0.6 and 0.3 seconds; there is no evidence for a cliff at any single number.

3. 3

   Give feedback immediately even when the real answer takes longer.

   Doherty and Thadhani's mechanism is about the user losing their held sequence of intent, not about the literal wait; an interface that acknowledges the click within about 100 milliseconds (see the RAIL guidance above) protects that sequence even while work continues.

4. 4

   Fix the step that is actually the bottleneck.

   In the report's own NIH case, deterioration built up gradually as concurrent users grew; the fix that paid off was capacity where the queue actually was, not a general instruction to speed up the whole system.

5. 5

   Expect diminishing room to matter below a few tenths of a second.

   The report's fastest measured point is 0.25–0.3 seconds; nothing in it supports chasing single-digit milliseconds for their own sake once a person is already the slower part of the loop.

It backfires when the speed you improved wasn't the one holding the user up. Naughton's fix at NIH worked because the delay itself was the bottleneck. A form that is slow to load but takes five minutes to read regardless will not get five minutes shorter because the server answered faster — the flow the finding protects is around the terminal, not around the reader's own thinking.

091 min

How to spot the Doherty Threshold going wrong

The tell that this finding is being misapplied is a mismatch between a system metric and what people are actually doing with the extra speed. A dashboard showing improved server p50 latency with no change in completed-task counts is the clearest sign: the report's whole argument was that faster response shows up as more finished work, not as a chart that only engineering looks at.

Two other observable symptoms: users abandoning a task partway through even though the measured response time is sub-second — often a sign the delay was never the real obstacle, and the true bottleneck (a confusing step, a long form) got skipped past — and a system where load-time metrics improved but support tickets or repeated-attempt logs show people still re-entering the same command, the exact symptom Doherty and Kelisky described in 1979 as a broken "short-term mental memory buffer."

?6 questions

Questions people ask

§7 sources

Sources for the Doherty Threshold