Case Study 2 — Deep Dive: When a Paragraph Is Smooth but Says Nothing

A contrasting case. Case Study 1 fixed a paragraph that was coherent but not cohesive. This one tackles the harder, sneakier failure: a paragraph that is perfectly cohesive—it flows—and yet is incoherent, because it never makes a point. The vehicle is Raj Patel's open-source README, fictional but realistic.

The trap of smooth prose

Most writers, told to "make it flow," eventually learn to chain sentences smoothly. That is real progress—but it creates a trap. A paragraph can flow beautifully and still be empty, because cohesion and coherence are different things (§8.5). Cohesion is whether the sentences connect; coherence is whether they add up to something. Smooth prose can disguise the absence of a point, and the absence is harder to spot precisely because nothing snags your eye. This is the failure that survives a "make it flow" pass and gets shipped.

Raj inherited a neglected project and is rewriting its README. He wants an "Overview" paragraph explaining what the library is for. His first attempt flows just fine:

This library is designed to help developers work with data more effectively. It provides a range of useful features that make common tasks easier. When developers use it, they can accomplish their goals with less effort. This is valuable because developer time is expensive. As a result, the library can improve productivity across a team. For these reasons, it is a helpful addition to many projects.

Read it. Nothing clatters. The given-new handoffs are clean ("This library" → "It" → "developers use it" → "This is valuable" → "As a result" → "For these reasons"). The transitions ("As a result," "For these reasons") are even correctly causal. By the tools of Case Study 1, this paragraph passes. And it is completely useless.

Why it's useless: a coherence failure

Apply the second diagnostic question from §8.5: I followed every sentence—but do I know what the point was? Here, no. After reading, you cannot say what the library does. Does it parse data? Transform it? Validate it? Move it between systems? "Help developers work with data more effectively" is true of almost any software ever written. The paragraph flows from one empty generality to the next, and the smoothness is exactly what hides the emptiness.

This is cohesive but not coherent. The stitching works; the content has no controlling idea. And notice the giveaway: the abstraction (Chapter 3's enemy). Every noun is vague—"data," "features," "tasks," "goals," "productivity." There is not one concrete fact a reader could act on. A coherence failure and an abstraction problem usually travel together, because a paragraph with nothing specific to say has nothing specific to cohere around.

You cannot fix this by reordering—the order is fine. You cannot fix it with better transitions—they're already correct. The only fix is to supply the missing controlling idea, which means Raj has to answer the question he was avoiding: what does this library actually do? That is theme 1 in action (writing is thinking): the flat paragraph was a symptom of an un-pinned thought. The prose couldn't be specific because Raj hadn't forced himself to state, concretely, what the thing is.

The repair

Raj stops polishing and answers the real question. The library reads CSV and JSON files, validates them against a schema, and reports errors with line numbers. That is the controlling idea. Now the paragraph can cohere around something:

This library validates tabular data files (CSV and JSON) against a schema you define. Point it at a file and a schema, and it checks every row, reporting each violation with the exact line number and the rule it broke. It is built for the moment before you ingest external data—catching malformed records at the door instead of three steps downstream, where the failure is expensive to trace.

Why it's better: Now a reader knows precisely what the library does (validates CSV/JSON against a schema), how (row by row, with line numbers), and why it matters (catch bad data at the door, not downstream). Every sentence carries a concrete fact. The topic sentence (§8.2) states the one idea; the rest develops it. And it still flows—coherence didn't cost cohesion. The handoffs remain clean ("This library validates..." → "Point it at a file..." → "It is built for the moment..."). You fixed the point without breaking the flow.

The general lesson

These two case studies are the two halves of "hard to follow," and they need opposite fixes:

The reason this matters in practice: when a reader says "this is hard to follow," your instinct is to start somewhere, and most people start by polishing sentences. But polishing helps neither failure. For Dana's paragraph it's wasted effort (the sentences were fine); for Raj's it's actively harmful (it makes empty prose prettier, burying the problem deeper). Diagnose first—which kind of hard?—then reach for the matching tool.

A note for the Software track

Raj's empty "Overview" is the most common README failure in open source, and now you can name it. The fix is always the same: replace abstraction with the concrete answer to "what does this do, specifically, and when would I reach for it?" That concrete controlling idea is what cohesion can then organize. Raj's full README makeover lands in Chapter 25—but it starts here, with the discipline of refusing to let smooth prose substitute for a real point.

Try it yourself

Here's a flowing-but-empty "Features" sentence from another README. Diagnose it, then rewrite it with a concrete controlling idea (invent plausible specifics):

"Our tool offers powerful capabilities that enable users to streamline their workflows and achieve better outcomes."