Refactoring
to
maintainability

The meaning of things

2023-09-11
Consultancy

The meaning of words is important. That is what allows us to communicate in a comprehensible manner. If two people give different meanings to the same word they will not be able to communicate in such a way that both sides get the same understanding. Without shared meaning, communication fails. Within a context, you need the same meaning.

The main factor in consultancy

As soon as you advance a little on your career as a software developer, you see that code is just a translation of business rules. And for that translation to occur properly, the communication of the business rules needs to be correct. If you don’t share a common vocabulary with the business, in which words have the same meaning, you can’t translate. And is not the business responsibility to know the language of the computer to be able to tell you how to translate, because if that were the case, they wouldn’t need your services. Communication becomes a more valuable tool than the code itself (there are other reasons why communication is useful, but we will not discuss here)

For a few years I understood that idea, where part of my work was to understand the business language, so I could design solutions accurately. But I had yet to understand that even on a business, there could be different meanings to the same words.

DDD

Eric Evans understood this. So on his Domain Driven Design book, he gave us the idea of the ubiquitous language, where the language not only needs to be common, but is domain specific. Each domain, has its own meaning for the same words. The idea that words in different context have different meaning is something that, at the most basic level we understand. The word net doesn’t have the same meaning when talking about football, basketball, fishing, or computing. Marketing and Fulfilment could use the same words, but they refer to different things.

The bandwagoners

If I talk about Agile, in the context of programming, I am talking about what appears in the Agile Manifesto. I am talking about the ethos of how to develop software. If you talk about “Agile” where you have non-negotiable, fixed processes … you have a different meaning for the same word. So our discussion is likely to start with miscommunication.

Sadly, words are easily co-opted by people, because they want to keep selling what they were selling before, just repackaged with the new hot name that was making the rounds. Sometimes we go through processes of renaming to fend off those that misuse of the word. But is a losing battle.

DevOps is an idea, a culture. A word co-opted to represent something different (a position that existed before).

One problem with this co-opting is that sometimes things like the No True Scotsman fallacy get bandied around erroneously, by people that don’t understand the original idea. They try to argue that approaches and process that are not following what was originally postulated are the same as the original idea. When you point out the difference, they use the fallacy like is the right retort (can’t remember this happening to me, but I have seen that happen to other people)

Give me meaning

Sometimes I have done (and probably still do) the same: Use some word in a context, with a meaning that is different to what others have within the same context. Not good for understanding. I developed an habit to go back to the source (when possible), to learn the original meaning, and discover if the meaning I have is the wrong one or not. Adapt where needed, translate in your head, and improve communication.


Return to Index

Unless otherwise stated, all posts are my own and not associated with any other particular person or company.

For all code - MIT license
All other text - Creative Commons Attribution-ShareAlike 4.0 International License
Creative Commons BY-SA license image