A Field's Timeline
Each turning point solved the bottleneck of the stage before it
Lay out the development of [field] as a timeline. Requirements: 1) 4–6 stages, each with an approximate era and a one-line theme; 2) for every turning point, what the previous stage was stuck on, what solved it, and what the new cost was; 3) which early approaches are still in use today and why they survived; 4) the assumption in the current stage most likely to be overturned next.
How to use
The years barely matter. The chain of bottleneck, fix, new cost is what makes a timeline useful.
Good for
- You've just entered a field: the terms are familiar but they don't form a map, and you can't see the main line
- You need to judge whether a 'new' technique is a real break or a repackaging, which takes knowing why the last round was replaced
Not for
- You only need current best practice — a selection, a procedure — and history adds nothing to the decision
- Change here is driven by outside events (regulation, war), so the technical line doesn't explain it
Example
Input
How have databases evolved over the last twenty years?
What you get
It should stage the story as single-node relational, then read replicas and sharding, then NoSQL trading consistency for horizontal scale, then NewSQL buying consistency back. Each stage needs the bottleneck, the fix, and the new cost such as cross-shard transactions. It should also explain why sharding survives on migration cost, and name the assumption most likely to fall next, such as strong consistency requiring a throughput sacrifice.
Common mistakes
- Listing products and papers by year with no bottleneck or fix, which leaves you unable to place anything new
- Reading newest as best, and missing that the incumbent persists because switching costs are high
Try tweaking it like this
- Ask for 'the three biggest route disputes and why each side won or lost', which carries more per line
- Add 'predict where the next bottleneck appears', turning the timeline into a judgment exercise