How a Simple “Go Check the Floor” Request Reveals Stream vs State Data Inefficiencies

1. “Go Check the Floor”

On a Wednesday afternoon you are added to a project group with 137 unread messages. The manager says, “Check the floor for details; it was discussed earlier.” You start from the newest message, wade through emojis, acknowledgments, back‑and‑forth wording debates, and a blurry screenshot, finally piecing together a tentative conclusion around message 89, which may still be wrong.

After twenty minutes you have produced nothing but a mental replay of scattered conversations.

This situation happens daily and feels inevitable, yet it is absurd: you are forced to act as a CPU that replays a log that should not be replayed by you.

2. State vs. Stream Data: Same Information, Different Cost

Opening Alipay and seeing a balance of ¥85 is a state‑type data : the current value is presented directly, O(1) read cost, independent of history.

By contrast, a transaction log records every change (¥100 → -5 → -5 …). To know the current balance you must sum every entry, an O(N) operation. The same amount of information thus incurs a cost difference of an order of magnitude.

The 137‑message chat is a stream that has never been consolidated; asking someone to “go check the floor” is equivalent to handing them an un‑settled ledger and demanding they compute the balance themselves.

Making people “climb the floor” essentially forces them to rebuild state from a stream—a absurd but daily workplace practice.

3. This Is Not a New Problem—Databases Have Solved It

Engineers already deal with this distinction: Message Queues are classic stream data, an ever‑growing sequence of immutable events. Databases store the current state, allowing O(1) reads.

No serious system replays the entire event stream for every query; instead it materializes the current state at write time—known as a Materialized View . The stream remains the source of truth (event sourcing), but queries hit the pre‑computed state.

In many teams, however, people use a message‑queue‑like approach for information that should be state: project progress, responsibility assignments, latest decisions are all current‑state facts but are buried in an ever‑growing chat stream. New members must re‑read and recompute, often incorrectly.

4. Human Brains Aren’t Meant to Replay Streams

According to Cognitive Load Theory (John Sweller), “extraneous cognitive load” is the unnecessary burden imposed by poor presentation. Forcing people to “climb the floor” creates pure extraneous load.

Working‑memory limits (Miller’s 7±2, later refined to about 4 chunks by Cowan) mean a person can hold only a few items simultaneously. Replaying a 100‑plus‑message chat exceeds this capacity, leading to errors.

Thus, people become slower and, more importantly, make wrong reconstructions.

Computers have long known to pre‑compute state because replaying long logs is slow; human brains should do the same because replaying long logs is not only slow but also error‑prone.

The Second Sin of “Going Up the Floor”: Silent Information Loss

Beyond slowness and mistakes, key information can silently disappear. Unstructured chat messages lack a clear checklist, so missing items go unnoticed. Structured documents or task fields make omissions obvious.

The cost of missing information is not an immediate error but later re‑work: someone acts on incomplete data, makes a mistake, and you enter a cycle of clarification that further reduces efficiency.

5. Why Task and Document Tools Win

Task‑management software and documentation tools excel because they inherently maintain the “current state.” A task card instantly shows whether an item is “In Progress” or “Done”; a document always presents the latest version.

Both act as materialized views, exposing O(1) read access. This satisfies the principle of a Single Source of Truth : the current conclusion resides in one authoritative place, not scattered across a chat log.

6. Not to Ban Chat, but to Clarify Responsibilities

Chat, phone, or face‑to‑face communication is highly efficient for pushing incremental changes (“The plan changed, see it”). The problem is not the medium but where the new “current state” is persisted.

Healthy collaboration separates responsibilities:

Stream (Chat) : pushes changes to the right people.

State (Task board / Document) : stores the resulting current conclusion in a universally readable location.

When only the push step occurs and the state is left in the chat, the next person must replay the entire stream again.

Three practical actions can be applied today:

Assign a single source of truth for each ongoing item—one card, one document, or one table row.

After every important change, spend a few seconds to record the new conclusion in that source.

When calling someone, share a link to the source instead of saying “go check the floor.” The link provides state; the phrase provides a stream.

Writing Docs Isn’t Time‑Consuming

Writing a structured document takes roughly the same time as sending a series of chat messages, unless the tool is unusable. The difference lies in persistence: the document stores the information in a structured, searchable form, while chat messages disappear.

Don’t obsess over fancy formatting; a clear, well‑structured document is enough.

If the “current state” lives scattered in chat logs, the problem isn’t poor comprehension—it’s that the information never had a proper home.

Bring the state back to its rightful place and let readers retrieve it with O(1) effort.