We, software engineers, often work to solve problems presented by non-tech guys.
It is part of our jobs to understand the problem and solution from their perspective, map it to code improving the solution in the process, adding value with technology.
Our clients bring their own vocabulary, and we must adapt to use that same vocabulary, in an effort to remove translation impedance (see more about the Ubiquitous Language).
Sometimes, to workout a solution, it is the other way around: we need to explain technical things to the business people.
But they don’t get tech lingo and it’s not their job to. The goal is not to turn them into software engineers, but just to establish common ground and move the conversation forward in the direction of the right solution.
For example, how would you explain the concepts of Relational vs NoSQL databases to a layman?
A simple explanation
Here’s how I like to explain it these days:
You know e-commerces, right? You understand the basics of an e-commerce: there’s the buyer, who puts an order, which is basically payment + shipping information with a bunch of products.
A database is a mechanism for a system to store and retrieve information. Imagine it as a bunch of boxes with things in them.
The Relational database
The Relational database organizes data like this: it has a box just for customers, another box for products and another for orders.
It then offers a way to establish a relationship between the things in these boxes, which explains why it is called Relational.
Each order in the Orders box is related to a customer in the Customers box. It is also related to one or more products in the Products box.
The relationships between these boxes enable you to easily discover things like “how many times has this product been ordered this month”: to answer that, you count how many times that product is related to orders since 1st of this month.
So this was the Relational database.
The NoSQL database
NoSQL also organizes information in boxes, but instead of having one box per type of information, it has one box per set.
One set could be the order bundled with its related customer and related products. Another set, hence another box, could be the customer with its last five products.
So you need one box per set of infos you would like to have. This means you need to know upfront what boxes you’ll need, which means careful planning, but you’ll be rewarded with faster load times.
And this was the NoSQL database.
Comparing the two databases
In the Relational database you trace the relationship between the boxes everytime you want to build a report. This allows for great flexibility, but can become slow if you have too much data to cross.
The NoSQL database, in turn, stores ready-made reports. Since each box contains bundled information, it can answer you really fast when you ask for the latest five orders of a customer, because that information is already constructed. But you see, the same information is repeated across different boxes, and it is also very cumbersome to relate information on demand. So you gain speed, but you pay the price of increased space and added work for keeping everything up to date in all those boxes.
Of course this is a dumbed-down explanation, but the point is that it is in a language that the client can easily understand. Again, it serves well the purpose of establishing common ground and allowing the conversation to move forward.
It is often safe to assume that the other person already knows what you’re about to explain. Different names, different context, but similar concepts… they already know it.
There’s hardly anything completely new to anyone, and if you use their existing knowledge it becomes much easier to explain anything to anyone.
You also open your mind to see things in a simpler way, which helps a lot when solving tough problems.