The importance of jargon

Few weeks ago I was listening the latest podcast of PunkinDev (in French), which was focusing on the Software Craftmanship perception.

At some point in the podcast, someone stated that he does not introduce the name of the practice (Software Craftmanship, DDD, TDD, Hexagonal architecture, etc.) because, among other thing, the people who get the introduction may already have encountered it and got a bad experience with it, leading to resistance.

I won't argue with their experience.

My master thesis director had an heuristic when it comes to writing: if you don't have to use a concept to make your point, do not mention it, otherwise, make it your point.

He was also quick to criticize Haskell I was using, as it was saying it was full of concepts.

Actually, I always find find this argument fallacious.

When we learn OOP, it comes with many layers:

• Imperative programming (statement, memory)
• OOP (Objects, classes, inheritance, interface, access control)
• Design patterns

When it comes to FP:

• Types, data-type, values
• Type-classes (with Category Theory inspired names)
• Implementation patterns

The main problem which is highlighted by newcomers is the unfamiliarity of the type-class naming.

Unlike OOP design patterns, type-classes are based on an mathematically-precise definition, and not analogies with other fields.

We could simply state, that names could be exchanged, and as long as relations are kept, everything is fine.

But jargon, is necessary not only to build bigger conceptual frameworks, but also to communicate between each other.

Sometimes, even using the same word can lead to radically different results, beyond polysemy.

A long time ago, one of my coworker introduced Hexagonal architecture, it was nothing like I'm used to implement it.

Jargon is not the end of the road, it is a starting point, an opportunity to learn and keep everyone going in the same direction.