iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A software project has the system its code actually implements—and the picture of that system people carry in their heads. The project works best when those models are close enough for users and developers to agree on what the software should do, what it does, and why. They are not automatically the same, and neither is identical to the design the team intended.
What are the two models?
Here, “the model in the software” means the system as implemented: its behavior, rules, data, and responses. “The model in someone’s head” means that person’s understanding of the system—what it is for, how it works, and what will happen when they use it. The title’s wording is best read as this distinction; the original authorial intent is not established.
It helps to separate three related things:
- The implemented system: what the software actually does.
- The intended model: what designers or developers mean the system to represent.
- People’s mental models: what users and developers believe the system does and how it is structured.
These can diverge. A developer may understand an internal rule that is invisible to a user; a user may expect a workflow that the implementation does not support. Research on programmers’ mental models treats people’s understanding of programs, programming concepts, and programming itself as a distinct subject of study. A 2023 systematic literature review describes that body of work as having a shared kernel of understanding, while noting that findings had been scattered.
Why does a mismatch matter?
People make decisions based on what they think the system will do. If that expectation differs from the implemented behavior or from the team’s interpretation of a requirement, the result can be a confusing interaction, an unmet need, or a defect.
#1 Best Overall
A 2005 paper on requirements analysis identifies differences between user and developer understanding as a source of problems in meeting user needs, as well as defects, cost, and schedule concerns. That is the paper’s stated concern, not a quantified rule that every mismatch causes those outcomes. The study discusses comparing user and developer mental models to help find ambiguous or duplicate requirements.
Software is intangible, and knowledge about it is often tacit: a person may know how a feature behaves without having written down the assumptions behind that knowledge. A 2010 preprint by Adrian Kuhn, David Erni, and Oscar Nierstrasz frames this as a challenge to maintaining shared understanding among developers. Their CODEMAP proposal explores a cartographic visualization in an IDE to give project participants a shared, stable spatial representation. The paper reports preliminary results from an ongoing user study, so it does not establish that the visualization is effective in general.
Rank #2
How can a team make its models visible?
Alignment is not a one-time documentation task. Teams can surface assumptions through discussion, explicit representations, and repeated checks against working software. The useful method depends on whose understanding needs attention and what kind of evidence will reveal a gap.
| Approach | Whose understanding it surfaces | How it works | What it can reveal |
|---|---|---|---|
| Shared conversation and metaphors | Primarily the team’s interpretation, with users included where appropriate | People explain a system using common language or an agreed metaphor | Conflicting assumptions or different meanings for the same term |
| Explicit representations | Users, developers, or both, depending on who reviews them | Capture requirements or relationships in a diagram, model, or other shared artifact | Ambiguous, overlapping, or missing requirements |
| Recurring coordination | Team members and, when present, customer representatives | Use regular check-ins and ongoing customer interaction to revisit understanding | New disagreements as work or requirements change |
| Interaction with working software | Especially users and people validating behavior | Compare stated expectations with observed behavior | Differences between what people expect and what the system actually does |
A 2014 conceptual analysis examines the agile practices of system metaphor, stand-up meetings, and an on-site customer through the lens of shared mental models. It offers a way to understand how these practices may support shared understanding; it does not prove that one practice is universally best or most effective. Read the analysis of agile practices and shared mental models.
Rank #3
What should a project check?
When a feature, requirement, or interaction is misunderstood, ask a specific question rather than assuming everyone needs more documentation:
- Whose model is missing? Is the gap between users and developers, among developers, or between the intended design and implementation?
- What is the disagreement about? Separate what people say they expect from what the software currently does.
- How can the assumption be made visible? Use a conversation, an explicit representation, or a demonstration of the behavior in question.
- When should it be checked again? Revisit the shared understanding during requirements work and coordination, and when people interact with the working system.
The 2023 systematic review’s search found 3,678 articles, selected 84 for further analysis, and reached a final set of 187 articles through snowballing. Those figures describe the review’s selection process; they are not counts of software teams, project outcomes, or studies proving that a particular alignment practice works. The review focuses on programmers’ mental models of programs, tasks, and concepts.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
