O
lly Wenn defends the value of jargon. Words are tools. You can't communicate properly without them and you need the right ones for the job. That means there's a place for jargon.
Different trades and communities develop specialised vocabularies so they can discuss the topics that specifically interest them. This is because they are dealing in detail that the layman may not appreciate. They need a more granular and precise way of describing specific components. For example, builders will tell you about the state of your soffits because that's their name for the underside of the sticky-out bit of your roof, and they deal with them a lot. Physicists aren't trying to be standoffish when they talk about strangely named sub-atomic particles – they just want to make sure they don't accidentally tread on a rare one.
Specialised vocabularies help us to differentiate among items or qualities in situations where those differences really matter. Famously – but incorrectly – Inuit peoples are meant to have many different words for snow. In fact, skiers have different names for different types of snow too. I bet people who study avalanches have a whole set of other terms geared to the way snow (mis)behaves when it decides to try skiing itself.
In the software world, all our work starts and ends with words. If we're to build a system correctly, or successfully integrate one with another, we have to get rid of any ambiguities that might lead to expensive mistakes. So, if someone wants “a website where it's easy to put up blogs”, we need to make sure we know what they mean by “blog”. Many business people use “blog” and “blog post” interchangeably. The customer might mean they want to be able to post to one blog easily, or that they want to be able to set up new blogs easily.
There are good and bad ways to eliminate this kind of potential misunderstanding. The bad way is for the technology guy to deliver a lecture on the origin of the word “blog”. The good way is to acknowledge that there are potentially two functions at play here and that the customer might in fact want both. This way the technology team is helping the business articulate its needs and reimagine its goals.
Language issues become arguably even more important in the testing and live phases of a system. As bug reports are written by users (ie real people) it's always possible that they will miss a distinction that is vital to problem investigation and resolution. In the engineer's world, there are many different varieties of “it's not working”. Just as the skier sees different types of snow, the engineer sees different types of malfunction. “The system just hangs.” Is it the application that hangs, or the computer? Can you do anything else with the application, or is it just this one function that doesn't work? And when you say it hangs – what actually happens? “Oh, it gives an error message.”
Bug reports and change requests shouldn't be treated as holy writ. They exist to initiate a conversation which will develop into a diagnosis and a plan of action. You wouldn't send your doctor a note saying “I have a headache” and then wait for her to come back to you with a cure. Technology people should not abandon their (useful) jargon. But they must be ready to explain why the concepts denoted by the jargon matter.
Zolv can't help you with your soffits, but we're good with software. For straightforward discussion about travel sites that sell, get in touch with us.
