WIN #011: Most Probable Reasons for SW Development Team Misunderstandings

[click to enlarge]
What are the most likely reasons for misunderstandings within a software development team? I explore the most probable culprits within this week’s newsletter.

 

#1

❓ How come SW developers do not understand each other? Why can’t they effectively collaborate immediately after they are put on the team?

πŸ’‘ Turns out that most used terms are not universally understood the same way. In fact the more the word is widespread the less common understanding there is!

πŸ“š Martin Fowler coined the phrase *Semantic Diffusion* to describe this phenomenon.

Semantic diffusion occurs when a word is coined by a person or a group, with usually a pretty good definition, but then is spread throughout the community in such a way that it distorts or weakens its original meaning.

It happens every time with things that become popular within the SW industry. Most developers get acquainted with the idea only superficially, adding their interpretation as they spread the idea further.

Take for example “refactoring” as a term. The odds are that two developers you interview about the meaning would come up with at least some differences in understanding, if not with the totally opposite.

Moreover, there is no real effort within a group to get to a common understanding, but the word is further used with frustration turning into despair.

The more popular the term, the more widespread it is, resulting in more distortion of the meaning.

❗️ Here are some of the popular examples that are widely misunderstood, lost their original meaning, or turned into their opposite: Refactoring, DevOps, Agile, Code review, Testing, Unit Testing, Quality Assurance, TDD, BDD, Microservice, Team, Collaboration, Continuous Integration, Continuous Delivery, Trunk Based Development, User Story, Spike, Proof of Concept, Pair Programming, etc.

πŸ’‘ Don’t assume that just by using a word, the word would be universally understood within your group with the same meaning you are using.

πŸ’‘ Seek the common understanding of confirmation of meaning within a group before proceeding to use the term or a phrase.


 

#2

❓ Is semantic diffusion that bad? How can the meaning of a word be that distorted?

πŸ’‘ It is not that rare that through semantic diffusion the meaning of a word becomes so distorted that people start using it in its *opposite* meaning instead.

πŸ“š As discussed above Martin Fowler coined the phrase “Semantic Diffusion” describing how the meaning of a word becomes distorted by using it without proper understanding and propagating it further. The more widespread the use the more emphasized the effect.

Martin Fowler is the creator of another neologism – Semantic Inversion.

When the meaning of a word becomes so distorted it starts meaning quite the opposite.

Notable examples are:

➑️ MVP (Minimal Viable Product) πŸ‘‰Β instead of a minimal product increment intended for quick feedback and experimentation, the meaning became so distorted that many people think quite the opposite – fully-featured first version of a product; instead of weeks to the feedback, to many people it means months to production.

➑️ DevOps πŸ‘‰ instead of a set of practices and a mindset, to most people it means a separate operations team or SysAdmin2.0

➑️ Cross-functional team πŸ‘‰ instead of a group of people with OVERLAPPING skillsets, so they can collaborate tightly, it seems like most people understand it as a group of people with COMPLEMENTARY skillsets, with no overlap of skills; instead of breaking silos within the group, they are further reinforced.

➑️ Code refactoring πŸ‘‰ instead of restructuring the code in small steps so the functionality is maintained, to most people it means a large-scale redesign of a solution, often by changing existing functionality.

πŸ’‘ It is of utmost importance to get to a common understanding of whatever terms are being used within the team.

πŸ’‘ A quick sharing of meaning or establishing a common meaning within a group is vital and will save you huge amounts of frustration and headaches down the road.


 

#3

❓ Most highly-effective practices do not apply to my team! They require all-star teams!

πŸ’‘ While it might look like so, this may mean that your team simply does not know how to employ those.

Most developers have been exposed to techniques, approaches, practices, and trends available to them through teams and companies they have been working with. Unfortunately, these trends favor popular stuff, trendy things, and fads.

❗️ As a consequence, older, valuable, and validated knowledge tends to get lost since it is no longer available through the trends and fads.

That’s what I call Cognitive Exclusion.

It is a form of Recency Bias. While Recency Bias favors recent events in decision-making, Cognitive Exclusion means that the subject is unaware of prior events.

πŸ’‘ Here is an example of Cognitive Exclusion:

Git is by far the most popular choice of a version control system. It’s been around since 2005. And it undoubtedly brought and democratized quite useful capabilities.
Since around 2010, its popularity soared, which pushed all other alternatives into obscurity. Sadly, at the same time, the popularity of GitFlow and its likes soared as well.
Today, most younger developers don’t know any better, and their teams struggle to employ trunk-based development, continuous integration, and continuous delivery as a consequence.

πŸ“š This can be easily deduced from the latest State of DevOps report I wrote about.

πŸ’‘ To avoid the Cognitive Exclusion pitfall, explore alternatives carefully, and seek to understand the trend itself.


 

#4

❓ How can one effectively fight misunderstandings within a team and the frustration caused by them?

πŸ’‘ Here is a knowledge acquisition process following the fallacies described above, further describing how to fight them (Semantic Diffusion, Semantic Inversion, and Cognitive Exclusion) ‡️

Acquiring a skill or relevant knowledge generally flows through a handful of phases:

1️⃣ “I don’t know that I don’t know” – indicates that a person is unaware of a skill or a concept.

Generally speaking, we are not aware of the existence of any concept or skill until we are exposed to it. This puts us in a position where we don’t know that something exists, thus “I don’t know that I don’t know anything about that, obviously since I don’t know that it even exists.”

E.g., newcomers to SW development mostly don’t know that alternatives to “Agile methodologies,” “GitFlow,” or “End of Sprint testing” exist. So they accept it as a norm and the way things are and should be.

It is where Cognitive Exclusion originates.

2️⃣ “I know that I don’t know” – when exposed to a skill or a concept, a person is aware of its existence but doesn’t know nor understand it.

Given the ever-growing cognitive load and vastness of information required and available, developers are often tempted to assume meaning, especially of concepts not in their immediate focus of interest.

Semantic Diffusion and Semantic Inversion originate here.

3️⃣ “I know that I know” – a person learned a concept or a skill, so he/she is in conscious command of it.

A new skill or a concept is learned and is applicable with more or less cognitive investment, i.e., we have to think about it when we apply it.

It is important to be aware of the quality of information and knowledge acquired in this stage. It is where Semantic Diffusion and Semantic Inversion thrive if allowed.

4️⃣ “I don’t know that I know” – a person is in such an advanced command of a skill or a concept, so it is used unconsciously, i.e., without thinking.

Having mastered a skill or a concept, we use it efficiently without (much) thinking. It is our area of expertise and our safe zone.

❗️ Being reasonably suspicious of what makes us confident here is crucial. Reiterate on obvious and accepted, especially when challenged. E.g., “in-process phase-gate code reviews are a best practice in SW development.” Here one should reexamine his belief objectively.

πŸ’‘ Understanding what frustrates and demotivates team members is crucial in improving team effectiveness.

πŸ’‘ Misunderstandings and differences in understanding are common causes for such frustration and loss of motivation.

 

Build highly effective software development teams

Subscribe to the weekly ideas newsletter and get tips and insights to help you with building highly effective software development teams. You’ll get tips on how to do so every week.