Anatomy of a Misunderstanding

Much of the value we add as engineers comes from applying our skills beyond the IDE.  Engineering requires precise attention to detail and prolonged focus.  This combination can be particularly helpful in identifying spoken misunderstandings as they occur, before they become a problem.

Having technical conversations is tough.  First, most conversation is casual in nature.  This fosters habits that are counterproductive to discussing technical topics.  Second, speaking precisely about technical topics often requires more time then listeners are willing to give.  The speaker needs to express themselves concisely.  They also need to avoid going off on tangents unnecessarily.

Groups tend to explore topics in a breadth-first manner, lightly exploring a number of perspectives.   For a technical conversations to be productive however, it must reach some conclusions by exploring a specific line of thought in depth.  People don't naturally converse in a depth-first manner though.  It has to be forced somewhat.  This is true for various reasons.  In depth exploration requires focus.  People get tired and lose focus.  People get distracted and may get lost.  People may not value the line of conversation equally and zone out or change the subject.  Finally, as the group approaches the point of conclusion, some degree of conflict often arises and people have varying levels of discomfort with this.

The process of coding is itself a depth first exploration of a problem domain.  Many of the same skills built up by experienced coders can be applied to enhance the productivity of group technical discussions.  These often take the form of identifying misunderstandings before they compound.  Anyone aware of the patterns can apply them and with practice develop an intuition for them.

 

Same Name, Different Things

Speakers use the same name to refer to distinct ideas.  This can happen when language used is too vague, when words used carry multiple meanings, etc.  Ubiquitous Language as espoused by Domain Driven Design can help alleviate this.
 

 

 Multiple Names, Same Thing

Speakers use different names to refer to the same idea.  This often happens when the idea is new, it's not yet well understood by the group, or the groups are unfamiliar with each other.

 

Multiple Perspectives, Same Thing

Speakers disagree despite talking about the same idea because they each have incomplete information about that idea and aren't yet aware that they're talking about the same thing.
 

 

 

 

Superset/Subset

Speakers use the same name to refer to different levels of a hierarchy or superset/subset. 

Linguistic

 

 

 

1. Passive tense - the agent of action may be unsaid or ambiguous leading to multiple disparate interpretations

2. Dangling participle - an object other than the speaker's intended one gets modified, leading to multiple disparate interpretations

3. The use of a lingua franca can cause interpretation troubles.  One example is the negative interrogative.

 Example

A: "It's not done?"

B: "No."

In British and American English B's response, "No" is addressing A's "it."  As in "No, it's not done."  English in other regions may interpret this differently.  "No," may address the accuracy of the overall question as an assertion.  As in, "No, that is incorrect, it IS done."  For brevity we may simply say "Yes" or "No" but in fact mean exactly the opposite, despite speaking the same language.

 

Conclusion

The earlier a software mistake is found, the less impact it has.  Conversation always proceeds code.  Hopefully, by applying some of these patterns to technical discussions, we can prevent misunderstandings before they become problems in our software.