In The Science of Screwing Up, Wired Magazine discusses Kevin Dunbar: “a researcher who studies how scientists study things — how they fail and succeed”.
When Dunbar reviewed the transcripts of [a meeting involving people from numerous disciplines], he found that the intellectual mix generated a distinct type of interaction in which the scientists were forced to rely on metaphors and analogies to express themselves. (That’s because, unlike [his comparison group of specialists,] the E. coli group, the second lab lacked a specialized language that everyone could understand.) These abstractions proved essential for problem-solving, as they encouraged the scientists to reconsider their assumptions. Having to explain the problem to someone else forced them to think, if only for a moment, like an intellectual on the margins, filled with self-skepticism.
Interestingly, the Domain Driven Design book makes a similar plea:
When domain experts use this LANGUAGE in discussions with developers or among themselves, they quickly discover areas where the model is inadequate for their needs or seems wrong to them. The domain experts (with the help of the developers) will also find areas where the precision of the model-based language exposes contradictions or vagueness in their thinking.
However, I find the essence of the two discussions to be slightly different:
- The Domain Driven Design book encourages developers and architects to move towards one language, that can be shared between the stakeholders.
- Dunbar found that the process of “working around” the differences in the languages and concepts produced the real results, of finding a common understanding. I think the correct solution lies somewhere between these two extremes.
