Case Study 2 — Half a Page to Say What's New: A Related Work Rescue

A composite, fictional-but-realistic scenario. The reviewer comments are the kind real program committees write; the paper and citations are invented ([1][8] stand in for real references). This is the same synthesis skill as Case Study 1, compressed into the unforgiving space of a CS conference paper.


The situation

Maya is submitting a systems paper to a conference. Her contribution is genuinely good: a cache that learns a workload's access pattern online, with no offline training phase, and coordinates across nodes in a distributed setting. She has half a page for Related Work, and here is what she wrote:

MAYA'S DRAFT — Related Work:

"Caching has been studied extensively. Lee et al. [1] proposed an LRU
variant that improves hit rates. Gupta and Smith [2] used machine
learning to predict cache hits. Tanaka [3] introduced a time-aware
eviction policy. Ferreira et al. [4] studied caching in distributed
databases. Wang [5] proposed an adaptive replacement policy. Cho and Park
[6] applied reinforcement learning to eviction. Dubois [7] examined
caching on edge devices. Eriksson [8] proposed an energy-aware policy.
Our work also addresses caching."

A reviewer's comment comes back blunt: "The Related Work reads as an annotated bibliography. After eight citations I still cannot tell what is new about this paper. How does your approach differ from [2], [5], [6]? Please position your contribution."

What went wrong

Maya's section is a citation dump (§15.7) — the Related-Work form of the source-by-source failure from Case Study 1, just compressed. The symptoms:

  • One sentence per citation, eight in a row. Each is a mini-summary ("Lee proposed…, Gupta used…, Tanaka introduced…"). The grammatical signature of summary (author-as-subject) is back, in miniature.
  • No grouping. Eight papers are listed as eight separate items, when several plainly belong together (Gupta and Cho both use learning; Lee, Tanaka, Wang all refine eviction heuristics).
  • No organizing dimension. There's no axis along which prior work is mapped — so the reader gets a pile, not a landscape.
  • The killer: "Our work also addresses caching." This announces a topic, not a contribution. It answers "what is this about?" when the reader's only question is "how is yours different?" After eight citations, the section has not answered it — which is exactly the reviewer's complaint.

The space constraint makes this worse, not better. With half a page, Maya can't afford to spend it summarizing eight papers one at a time and then have no room left to say what's new. The citation dump is doubly wrong under a word limit: it wastes the scarce space and fails the job.

The fix: group, characterize by limitation, position

Maya rebuilds using the §15.7 recipe. First she finds the organizing axis: prior caching policies vary on how they decide what to evict — by fixed heuristic, or by learning — and on where they operate — single node, or distributed. That axis becomes the structure. Then she groups the eight papers into camps, characterizes each camp by its limitation (because the limitations set up her contribution), and ends by positioning her work on the axis no camp covers.

❌ Before (citation dump, no contribution visible): "Caching has been studied extensively. Lee et al. [1] proposed an LRU variant... [eight one-sentence summaries] ... Our work also addresses caching."

✅ After (grouped, characterized, positioned): "Prior caching policies fall into two camps. Heuristic methods refine classic eviction rules — LRU variants [1], time-aware [3] and adaptive-replacement [5] policies — and are cheap to run but blind to workload structure. Learned methods [2, 6] predict access patterns and adapt better, but require an offline training phase and degrade when the workload shifts. A separate line of work addresses distribution: distributed caches [4] coordinate across nodes but inherit whatever single-node policy they are built on, and energy- and edge-focused variants [7, 8] optimize for deployment constraints rather than adaptivity. Our approach occupies the gap none of these covers: it learns the workload online, with no training phase, and is designed for distributed coordination from the start — combining the adaptivity of learned methods with the deployability of heuristic ones."

Why it works: Same eight citations, transformed. Watch the three moves: (1) Grouping — the eight papers became three camps (heuristic / learned / distributed), and citations now appear bundled ("[1], [3], [5]") as instances of a camp rather than as eight separate sentence-subjects, which is what makes synthesis fit in half a page. (2) Characterized by limitation — each camp is tagged with what it lacks ("blind to workload structure," "require offline training," "inherit their single-node policy"), because the limitations are the runway for the contribution. (3) Positioned on a named axis — the last sentence states exactly what's new ("learns online, no training, distributed from the start"), placing the contribution in the one region the map left empty. The reader now knows, in a single sentence, how Maya's work differs.

The rebuilt section is shorter than the dump — grouping compresses — yet it does the job the dump couldn't. The reviewer's question ("how does yours differ from [2], [5], [6]?") is now answered explicitly: differently from the learned methods [2, 6] because there's no training phase; differently from the heuristics [5] because it adapts; differently from the distributed work [4] because adaptivity is built in, not bolted on.

A note on fairness

Notice Maya characterized the camps by scope limitations, not by calling them bad. "Learned methods require an offline training phase" is a fair, specific, checkable distinction. "Learned methods are inferior" would not be — and it's reckless, because the author of [2] or [6] may be reviewing her paper. Critique the scope, never the competence (§15.7) — a principle that returns in Chapter 34's treatment of code review: you distinguish your work from prior work without disparaging the people who did it. Fair positioning persuades reviewers; dismissiveness makes enemies of the exact experts judging you.

The outcome

Maya's resubmission keeps every citation but reorganizes them into a half-page that a reviewer can read in thirty seconds and come away knowing precisely what's new. The contribution that was invisible behind eight summaries is now the punchline of the section. Same literature, same space, opposite effect — because she stopped listing prior work and started positioning against it.

The takeaways

  1. A Related Work section answers one question: "how is yours different?" If a reader finishes it not knowing what's new, it has failed — no matter how many papers it cites.
  2. Group, don't list. Bundling eight papers into three camps is what lets synthesis fit under a word limit. Grouped citations ("[1], [3], [5]") are the surface sign of digested literature; one-sentence-per-citation is the sign of undigested literature.
  3. Characterize each group by its limitation. The limitations are the setup for your contribution — they're the gap argument (§15.6) compressed into a clause.
  4. End on your contribution, explicitly, on a named axis. "Our work also addresses caching" is a topic; "ours learns online and is distributed from the start, which no prior camp does" is a contribution. Make the reader's inference for them.
  5. Be fair to the work you distinguish yourself from. Critique scope, not competence — the author of the paper you're contrasting with may be your reviewer.

One sentence to remember: Related Work isn't where you prove you read the field — it's where you show, in one axis and one positioning sentence, the shape of the hole your paper fills.