industry-practice-survey

Systematically survey how multiple mature industry implementations handle a specific design problem, then compare them to extract consensus (everyone does it this way) and shortcomings (no one does it well) as a reference for your own design — adopt the consensus, avoid the shortcomings, and make explicit where you will surpass them. This skill is a discipline for "survey-and-borrow", addressing three failure modes: reinventing the wheel from scratch, copying an industry pitfall along with the practice, and mistaking a shared shortcoming for consensus. The methodology is generic and not tied to any scenario or stack.

When to use

• The user asks "how does the industry / how do others / how do mature products do X", "is there an existing pattern for this design", or "is there anything I can reference"
• Before a design decision, examine how mature products handle the same kind of problem, then decide your own approach
• Not confident in your own solution and want to cross-check it against industry practice
• Distinguishing whether a given approach is "industry consensus" or "a workaround forced on one party"

When NOT to use

• Pure factual lookups
• Comparing two of your own options to pick one (that is deep-comparison-analysis)
• Internal decisions that need no external reference

Core question: why survey industry practice

Designing from the gut incurs three typical losses:

The deliverable of a survey is not "copy one implementation"; it is distilling, after comparing multiple, what to adopt, what to avoid, and what to invent.

Methodology (six steps)

① Focus the question

State the design problem as a researchable question — only a specific question can be compared across implementations.

• Bad (too vague): "How does the industry do remote control?" → No way to compare.
• Good (specific): "When switching control modes, how is the previous mode's controlled axis reliably zeroed to a stop?" → Each implementation's concrete handling can be compared.
• Test: Can this question be asked verbatim as "how does product X do it", and are the answers comparable?

② Pick comparison targets

Choose 2–3 mature industry implementations as comparison targets — either same-category (solving the same problem) or same-problem-shape (different category but identical problem structure).

• Same category: direct competitors (solving the same problem).
• Same problem shape: cross-category but identical problem structure (e.g., "discrete event vs continuous stream" appears in protocol design, UI events, and message queues).
• Pick mature products: ones validated at scale are more valuable references than niche or experimental projects.
• 2–3 is enough: fewer means no contrast, more means noise.

③ Systematically gather evidence (the core of this skill)

For each comparison target, dig out how it handles the problem, and the key is attaching evidence and strictly separating "verifiable" from "inferred / not observable".

• Evidence-gathering means (pick by availability): read source code (open source / decompiled), read official docs and specs, read technical blogs and papers, search public materials, ask maintainers directly.
• Attach evidence: every claim gets an "evidence source" (file:line / doc section / spec clause); no bare assertions.
• Separate verifiable from inferred (key discipline):
  • Verifiable: logic you can directly see in source or docs.
  • Inferred / not observable: obfuscated, lives in a layer you cannot see (frontend→backend, client→server), or reverse-inferred from behavior.
  • Mark every claim as "verified" or "inferred"; do not pass inference off as fact. This step determines the credibility of the comparison table.
• Typical traps: assuming a variable that gets assigned also takes effect (it may be dead code); assuming logic you cannot see does not exist (it may live in a layer you cannot observe).

④ Multi-target comparison table

Lay the gathered evidence out as an object × dimension table. The dimensions are decomposed from the problem itself (e.g., "trigger path / feedback mechanism / in-flight lock / conflict arbitration / cancellation").

• Each cell: "this object's concrete handling on this dimension + evidence strength (verified / inferred)".
• The value of the table is horizontal comparability: for the same dimension, what each of three does, with differences and commonalities visible at a glance.
• Do not just write conclusions; include the "how" mechanism (so you can judge whether to adopt or avoid).

⑤ Distill consensus and shortcomings

From the comparison table, distill two categories:

• Consensus: a convergent practice across multiple implementations (e.g., "all use an independent path", "all use a particular mechanism") — validated by the industry, usually the thing to adopt.
• Shortcomings: areas where multiple implementations do it poorly, rely on a side to absorb slack, or do it crudely (e.g., "none provide completion feedback", "none lock inputs and rely on side arbitration") — these are what you surpass, not what you copy.
• Telling them apart: to judge whether a "multiple implementations all do this" pattern is consensus or shortcoming, look at whether it is right — done well and reasonable = consensus; done crudely or with hidden risks = shortcoming.
• Watch out: do not treat "one party's peculiar choice" as consensus (it may just be one party's tradeoff); do not treat "a shared shortcoming across multiple" as consensus (that means none of them solved it well).

⑥ Three tiers of recommendation

Based on consensus and shortcomings, give three tiers of recommendation:

The three-tier recommendation is the core deliverable that distinguishes this skill from "copy one implementation" — the goal is not to match industry baseline but to stand on industry's shoulders and make explicit where you surpass it.

Output template

# Industry practice survey for {problem}

## 0. Focused question
{a researchable question}

## 1. Comparison targets
- Target A: {mature implementation} (evidence availability: source / docs / ...)
- Target B: ...
- Target C (optional): ...

## 2. Evidence gathering (per target, mark verified / inferred)
### Target A
- Dimension 1: {handling} (evidence: file:line / doc section — verified / inferred)
- ...

## 3. Multi-target comparison table
| Dimension | Target A | Target B | Target C |
|-----------|----------|----------|----------|
| Trigger path | ... | ... | ... |
| Feedback | ... | ... | ... |
| ... | ... | ... | ... |

## 4. Consensus and shortcomings
- Consensus (to adopt): ...
- Shortcomings (to surpass): ...

## 5. Recommendations (Adopt / Surpass / Invent)
- Adopt: {industry consensus}
- Surpass: {industry shortcoming, the point where you must be solid}
- Invent: {no industry precedent, must define yourself}

Relationship to other skills

• Distinguished from deep-comparison-analysis (linked from there): deep-comparison-analysis is "compare two of your own options and converge on one" (do I pick A or B); this skill is "survey external mature industry implementations to borrow" (how others do it, for reference). Different objects (own options vs external industry), different purposes (pick one vs adopt / avoid / surpass). Selection comparison goes to deep-comparison; survey-and-borrow goes to this skill.
• Complementary to comm-link-debugging: the latter is the methodology for "comm link troubleshooting and localization"; this skill is the methodology for "survey and borrow".
• Usable as a precursor to design / selection: before selection in tech-selection-convergence or implementation in guide-and-manual, use this skill to see how the industry does it, so selection and design stand on industry's shoulders.

Practice reference (optional, as an appendix example)

The methodology is fully generic. If a project already contains a complete case of "systematically surveying multiple industry implementations for a design problem and comparing them" (e.g., surveying 2–3 competitors' implementations of a feature, or comparing how several open-source frameworks handle a problem), it can be referenced as an appendix example — walk the six steps over that concrete survey. But the methodology does not depend on any case existing.