Using Metaphors and Analogies in Technical Writing
5 exercises — identifying, choosing, and extending technical metaphors (circuit breaker, pipeline, sandbox, container, garbage collector) appropriately in IT documentation and blog posts.
0 / 5 completed
1 / 5
A tech lead writes: "Like a circuit breaker in electrical systems, the software circuit breaker trips and stops requests flowing to an unhealthy service." Which type of language technique is being used?
Option C is correct. An analogy draws a structural parallel between two domains to explain how something works. Here the entire behaviour of the software pattern (trips, stops flow) is mapped onto the electrical concept. A simile (option B) uses "like" or "as" for a surface comparison — "like a circuit breaker" is the simile trigger, but the full structure goes beyond comparison to functional explanation. A metaphor (option A) asserts identity directly ("the circuit breaker is…"). In technical writing, analogies are the most useful device for explaining unfamiliar concepts through familiar ones.
2 / 5
An architecture document describes a Kubernetes namespace as: "A sandbox for your workloads — isolated, self-contained, and easy to tear down." What is the risk of using the metaphor "sandbox" in technical documentation?
Option B is correct.Overextension is the key risk with technical metaphors: when the source domain (physical sandbox) implies stronger isolation than the target (Kubernetes namespace) actually provides. A sandbox implies complete separation, but namespaces share the host kernel — privilege escalation is possible. Technical writers must signal the limits of a metaphor to avoid creating false mental models. Option A is incorrect — even established technical metaphors can mislead. Option D is wrong — metaphors are valuable in technical writing when used carefully and with explicit scope. Option C misidentifies the grammatical form.
3 / 5
Which sentence correctly extends the "pipeline" metaphor in technical writing without overreaching?
Option A is correct. A well-extended metaphor maps the source domain (factory assembly line) onto the target (CI/CD pipeline) at multiple structural points: raw materials = code, assembly stages = build/test steps, finished products = deployable artefact. The analogy is explicit ("just as") and scoped. Option B overextends: "pressure builds up" has no meaningful CI/CD equivalent and introduces a false model. Option C anthropomorphises ("alive", "smell") in ways that are misleading and informal. Option D is wrong — dismissing useful metaphors because they are not perfectly literal is poor technical writing practice.
4 / 5
A blog post explains garbage collection: "The garbage collector is like a night janitor — it quietly cleans up memory that is no longer being used while your program sleeps." What type of metaphor device is "night janitor" here, and is it appropriate?
Option B is correct. This is a concrete-domain metaphor — it maps an abstract computational process (garbage collection) onto a familiar physical role (janitor). It correctly conveys three properties: automatic operation, background execution, and clean-up of discarded resources. For a general or introductory audience, this is effective. Option A is incorrect — personification is acceptable when it aids understanding. Option C is historically inaccurate. Option D is overly literal — all metaphors involve domain mismatches; the test is whether the mapping is useful and accurate at the intended level of abstraction.
5 / 5
A technical specification uses the phrase "container" to describe Docker containers. A colleague argues this is a metaphor. Is it, and does it matter?
Option A is correct.Dead metaphors are metaphors so well-established that their original source domain no longer actively influences meaning. "Container", "pipeline", "sandbox", and "garbage collector" are all dead or nearly-dead metaphors in software engineering — their technical meanings are primary in context. Explaining the shipping container origin in every specification would be redundant and distracting. Option B is incorrect for this reason. Option C is wrong — "containing" code and its dependencies is precisely what Docker containers do, making the metaphor accurate. Option D is incorrect — technical language is full of productive metaphors.