I2.10.3revise ETA continuouslydesign

Revise the estimate as progress continues; do not freeze the first figure

Aliases: live remaining-time · don't lock the first ETA · online update

What it is

Extrapolation’s ingredient is the rate “so far”. Every further completed stretch adds ingredient, so the estimate should move with it. Computing “12 minutes left” from the first two seconds and freezing those 12 minutes until the end is locking the most-informed moment to the least-informed one. Continuous revision is not flip-flopping. It is the estimate as a living quantity: the window updates, the number or range updates. Freezing is what dresses an early guess as a promise.

Why it happens

Information grows with completed work. At the start the window is short, homogeneity is unknown, variance is high. Halfway through, the transfer segment has a history long enough that variance should narrow. Freezing refuses the second half’s evidence. If the early stretch was fast (buffer filling, small files at the head), a frozen remainder looks too optimistic later; if the early stretch was slow (handshake, queue), a frozen remainder keeps scaring after work has already smoothed out. Revision lets the representation follow evidence.

The cadence of revision has to match the grain of the representation. A point estimate changing every second looks like jumping; a range can hold still inside the band and change on breach. Continuous revision means the estimate internally takes every new sample into the window, not that every new sample refreshes copy. Frozen internals and twitching copy are opposite diseases.

Where it stops holding

A countdown deadline (exam end, OTP) is not an estimate; it must decrement with the wall clock, not revise because “the load got faster”. When someone has already planned a departure against the current number, a large downward revision (suddenly almost done) may make them miss arrival; revision can still happen, but arrival notification must carry “ready early”, rather than assuming they are still watching. If revision is only allowed to grow longer, never shorter, the estimate is systematically pessimistic — sometimes a deliberate conservative policy, which must be named as “we will not under-report”, accepting that some people will feel padded. The window needs a floor: when too little is completed, a revision has no new evidence, and not updating is right — that is not the same as freezing the opening 12 minutes.

Applying it

  • Internally, update the window on every completed sample. Externally, publish at the representation’s grain: throttle a point estimate; change a range on band breach.
  • Do not lock “the first remaining-time computed” until 100%. The opening number is only that moment’s window talking.
  • On entering a new work segment, reset that segment’s window. Do not freeze the previous segment’s rate into the next.
  • How to check: watch a job that starts with a slow handshake then settles into steady transfer. If the opening remainder stays on screen until the end, mid-job true rate never entered the copy — it was frozen. Then check publish rate: if the second-count changes every second, split internal update from copy refresh.

Related

  • Same group: I2.10.1 Remaining-time estimates extrapolate recent rate; a rate shock makes them jump · I2.10.2 A range reflects uncertainty more honestly than a single precise number · I2.10.4 With no sound basis, show elapsed time rather than invent remaining
  • Nearby: I2.02 Predictable progress · I4.06 Countdowns and deadlines · I2.07 Perceived performance
  • Search terms: updating ETA · frozen estimate · online remaining-time

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/I2.10.3