A technological advance is a change in what is possible, not a change in what is being marketed. This page describes how to tell the difference, and how to decide whether a given advance has any bearing on work you are actually doing.
01Maturity, not novelty
The single most useful question about any advance is what stage it has reached. The stages behave very differently:
- Research result. Demonstrated under controlled conditions, usually by the party that benefits
from the result. Interesting; not yet a capability.
- Working demonstration. Reproduced outside the original setting, but with conditions chosen by
the demonstrator.
- Limited availability. Real users, real workloads, constrained access. This is the first stage
where independent evidence appears.
- General availability. Anyone can obtain it, and the failure modes are documented by people who
did not build it.
- Commodity. Widely available, competitively priced, and boring. Most advances that matter to
day-to-day work are in this stage, several years after they stopped being news.
Coverage tends to describe stage one in the language of stage four. Reading the stage correctly is most of the analysis.
02Whether it applies to you
An advance is relevant when it moves a constraint you actually hit. In practice that means asking which limit it removes:
- A capability limit — something that could not be done at all before.
- A cost limit — something possible but too expensive to do routinely.
- A speed or scale limit — something possible but too slow to fit the workflow.
- A skill limit — something possible but requiring expertise that was not available.
Advances that lower cost or speed limits change far more work than advances that add exotic new capability, because they convert occasional operations into routine ones. An advance that moves no limit you currently hit is not relevant to you, however impressive it is.
03Evaluating the claim
Some constraints do not move, and claims that appear to move them deserve extra scrutiny: physical limits, power and thermal budgets, network bandwidth and latency to a given place, the time it takes a human to review output, and the cost of being wrong in a regulated context.
Useful checks on any claim: were the conditions of the demonstration comparable to production conditions; has anyone unaffiliated reproduced it; what was measured and what was quietly held constant; and what is the failure behaviour, not just the success behaviour. An advance that works well on average but fails unpredictably is often harder to deploy than a slower method that fails in known ways.