What is in a Jargon?

During my interactions with engineers in various training programs, I noticed a common trend - they often used the term' story point' instead of 'user story' or simply 'story'. These engineers, all graduates from reputed educational institutions and had interned at well-known software development firms, seemed to be using the term interchangeably. While I did clarify the difference between 'user story' and 'story point' to them then and there, I believe there's a larger issue at play here that all professionals, not just those in software development, should be aware of.

Since most of us have to work in a team setup, communication becomes vital to successfully achieve the team/ organisational goals. Poor communication is costing the world a fortune every day. One of the common culprits of ineffective communication is ambiguity. We know a word is most likely to have multiple meanings and, hence, has to be interpreted depending on the context. This is inevitable because we can have only finite words but are left with infinite ideas to express. If you disagree with the finite words part, consider the impact of coming up with long words!

(Besides knowing a noun-based language such as English, If you know a verb-based language like Sanskrit, the impact of shorter words will be clear. The details may be for another day!)

Instead of using layperson's terms to explain our ideas in the professional world, we often resort to technical jargon. Jargon allows us to convey our ideas more quickly and effectively, using fewer words and making our communication more productive. However, it's important to strike a balance and not overuse jargon, as this can lead to excessive conciseness and increased ambiguity.

For communication with jargons to work, everyone involved must be aware of it. The professionals involved need to take the initiative to familiarise themselves with relevant jargons and help their team members get familiar with it. One also needs to understand the scope of jargons will be restricted to a specific context. The smaller the context, the more specific the meaning would be. A broader context might lead to varied interpretations, eventually reducing the benefits they offer (for example 'Agile').

In my opinion, the software engineering community has not done a great job coming up with jargon. Sometimes, we have multiple jargon with similar meanings. Of course, it's due to coincidence in some cases like Continuous Delivery vs Continuous Deployment. Also, there are jargons which don't help us anymore in communicating with unambiguity as professionals widely started using them to mean different things. 'DevOps', 'Agile', and 'Microservices' are definitely at the top of my list of such jargons.

If every professional in our industry pays attention to the above, it would definitely improve our lives as professionals.