We spend many hours in blogs, forums and twitter. How much we really understand each other, behind empathy, sympathy or antipathy?
The surprising hypothesis is that, yes, when we talk about computer programming and software development:
we are often talking from different parallel alternative universes
and we misunderstand each other because of the topic itself that is complex and slippery (what is called a wicked problem) and because we highly underestimate this complexity.
Really ?
Let's start mentioning well known and documented misunderstandings. Martin Fowler about Model View Controller or MVC architectural pattern says "one of the most quoted and most misquoted patterns around". Jeffrey Liker in The Toyota Way mention that 99% of the hundreds of organizations he visited fundamentally misunderstood Lean.
Let's look at direct experiences. I asked many people about the purpose of TDD and how they practice it in detail. I had many fundamentally different answers. I asked many people to comment SOLID principles while looking at lines of code and again I got many different answers. Same result when I listen to Velocity definition given by different Agile teams.
MVC, Lean, SOLID or Velocity are pretty old, well documented concepts and still different people from a practical point of view intend substantially different things. And in on-line discussions people often discuss using those names without recognizing the fundamental differences in the definitions. The situation is basically the same also for the other topics.
Misunderstandings seems to be the norm while the reciprocal understanding seems the exception.
Why ?
It's not an easy question. The matter have to do with
knowledge management,
ontology (the way things are),
epistemology (the way we know things) and
phenomenology (the way we perceive things). And things change with the characteristics of the topic.
Here I can tell things I observed in my own experience:
- Topics related to computer programming are by their nature abstract and intangible instead of concrete and tangible, they can also be generic instead of specific. I.e. consider SOLID principles that refer to a wide range of different problems, not a specific one, and apply to different languages and technology stacks not to a single language and a defined technology stack.
- Professional software development is an empirical process that depend highly on the context. Because of this decisions, trade-off, practices, solutions are highly dependent on the specific context of the project, the company, the market, the surrounding environment in general. While people participating in a discussion can refer to different contexts and keep many assumptions implicit, hidden, unspoken
- Furthermore professional software development is a practical activity and some aspect of software development can be fully understood only through practice and direct learning from people that have direct successful experience of that skill, or from emulations by observation of other experts. Books discussion and self-training can be not enough for some skill.
- Spoken language ambiguity is another reason, indeed for science we invented formal systems/languages
What have you observed in your experience ?
How to improve things ?
Things change with the characteristics of the topic. There is not one-size-fit-all answer.
Here follow possible suggestions for mistakes that I did.
- clarify a scope, small enough to be properly discussed on-line
- identify the context and make all the assumptions explicit
- don't rely only on abstract assertions and generalizations and instead focus also on practical concrete examples, eventually mixing the discussion with real (code) examples and practical (coding) activity. Dave Snowden says "allow language to emerge through our interaction with reality"
- recognize the limits of the spoken language and the topics that can be understood only through a direct shared practice/experience. Dave Snowden says "live the life, share the experience, intuitively understand the values"
- recognize the inherent complexity of some topics and of distributed discussions
More suggestions ?
And a final note,
A good dialog is oppositional and collaborative with the goal of understanding.
A worthless debate is a competition to prove the other side wrong.