Here, Domain Dependence is a practical label for a problem of transfer: a person can understand a sound principle in one setting and still fail to notice that it applies in another. Rolf Dobelli uses the term in his popular mental-model catalog. The research reviewed for this page discusses the underlying questions as analogical transfer, far transfer, reasoning schemas, or retrieval. It does not establish Domain Dependence as a standardized diagnosis or a single, universally accepted bias.

A garden plan that looks nothing like software

Consider this hypothetical scene.

Sana tests software for a living. When a build behaves strangely, she changes one condition at a time. Change the browser, the account type, and the network together, and the team will not know which change mattered.

On Saturday, she helps plan a volunteer community garden. The first proposal is to replace the soil mix, alter the watering schedule, and add shade cloth to every bed at once. Sana likes the plan.

Luis, another volunteer, asks, "If the garden beds were software tests, which variable would you change first?"

Nothing new has been taught. The question makes an existing rule visible in a setting that had looked unrelated. The volunteers revise the plan so comparable beds receive different changes. They still cannot control the weather or draw strong conclusions from a small garden, but at least they will not change everything at once and pretend to know what worked.

That gap between possessing a principle and recognizing its use is the problem this page calls Domain Dependence.

Why useful knowledge can stay in its original setting

A new problem can share the same relationship as an old one while looking different on the surface. Software builds and garden beds do not share much vocabulary. Their common structure is easier to state without the domain-specific nouns: if several possible causes change together, the result cannot identify which cause mattered.

In Gick and Holyoak's analogical problem-solving experiments, participants encountered a story that could guide the solution to a different-looking problem. Transfer fell markedly when they were not prompted to use the earlier story. The knowledge could be available in memory without being retrieved at the useful moment.

Later experiments by the same researchers found that comparing two analogous cases could help learners extract a shared problem structure. A summary, diagram, or verbal principle attached to one example did not reliably produce the same result. In negotiation studies, Loewenstein, Thompson, and Gentner also found that drawing an analogy across cases improved later use of the relevant strategy.

These are conditional findings, not a promise that one analogy will make knowledge portable. Transfer changes with the task, the distance between settings, the form in which something was learned, and the cues available later. Barnett and Ceci's review of far transfer argues that treating all of those changes as one effect hides important differences. Their review also finds substantial transfer under some conditions. Knowledge is not simply trapped in its first domain.

Familiar content is not enough

It is tempting to reduce the issue to familiarity: familiar examples help reasoning, unfamiliar examples hurt it. The evidence is narrower.

Cheng and Holyoak found that a problem could become easier when it evoked an applicable permission schema, even without experience of that exact rule. Griggs and Cox, however, failed to reproduce a broad advantage for thematic material in two experiments. Their improvement appeared when the tested rule itself belonged to participants' experience.

The safer conclusion is that content can help when it activates a useful rule or structure. A familiar setting by itself does not guarantee better logic.

Two nearby effects that work differently

Domain Dependence can be confused with context-dependent memory. In a classic study, Godden and Baddeley found that divers recalled word lists better when learning and recall took place in the same environment. That is evidence about environmental context and free recall. It is not direct evidence that a reasoning strategy will fail to cross from software into gardening.

Einstellung is different again. Luchins's problem-solving experiments showed how a practiced solution can make a simpler option harder to notice. Later work with expert chess players linked the effect to attention that remained fixed on features of a familiar solution. Einstellung begins with a method that has already come to mind and then blocks an alternative. Domain Dependence, as used here, begins with a relevant method that may not come to mind in the new setting.

What this means for expertise

Expertise does not automatically transfer to every task that shares part of its structure. It also does not become useless once the setting changes. The practical question is whether the new problem cues the right knowledge and whether the analogy preserves the relationship that matters.

This can matter whenever a team has already solved the shape of a problem but does not recognize it under new labels. A scheduling bottleneck may share a structure with a queue in software. A classroom feedback problem may resemble a measurement problem from quality control. Those comparisons are possibilities to test, not conclusions to accept because the metaphor sounds clever.

Real-Life Contexts

See Domain Dependence in everyday decisions

Pick a life context to see how this bias can show up outside the textbook.

When Debugging Skills Don't Translate to Feedback

A software engineer who routinely uses hypothesis-driven debugging to fix code finds it hard to apply the same structured approach when giving performance feedback to a colleague.

Illustrative scenario

Scenario

Maya works as a backend engineer at a midsize tech company. During sprint planning meetings she breaks down each bug into possible causes, tests each hypothesis with logs and unit tests, and records the outcome before moving on. Her teammates praise her for clear, evidence-based troubleshooting. One afternoon Maya is asked to give feedback to a peer, Luis, on his recent presentation. Instead of treating the feedback session like a debugging task, she relies on her impression of how Luis spoke, mentions a few vague strengths and weaknesses, and ends the conversation without asking for specific examples or checking whether her observations match Luis's own view. Later, Luis tells his manager that the feedback felt unfocused and didn't help him improve. Maya realizes she fell back on a casual, impression-based style because the cues she uses for debugging-logs, test results, step-by-step validation-were absent in the feedback conversation.

Where The Bias Enters

Maya's learned debugging routine is tightly bound to the concrete cues of code logs and test results. When those cues are missing in a feedback setting, her brain does not automatically retrieve the same hypothesis-testing process, so she defaults to a less structured, impression-based approach.

Decision Check

Before giving feedback, ask yourself: What specific evidence would I look for if this were a debugging task? How can I gather comparable evidence (examples, outcomes, metrics) in this conversation?

This scenario is illustrative. It explains the pattern and does not claim a documented public case.

Sources