Single Source of Truth for Beginners

Aimee
The Startup
Published in
4 min readSep 11, 2020
All rights to their respective owners.

A quick skim of Google search results won’t shed much light on what exactly is the “single source of truth” — or the SSOT. Wikipedia defines it as, “the practice of structuring information models and associated data schema such that every data element is mastered in only one place.” If your reaction was along the lines of, “Wait, what?” then you’re not alone. As a software engineering student, when I first heard this term, I thought it sounded more like a line from a Sci-Fi/Fantasy book series than a computer science concept. It was only until I put this into practice when learning about tables and object associations in Ruby, that I understood why this concept is so crucial.

First, it’s important to clarify that SSOT is an overarching computer science term and can be applied towards many languages. I’ll only concentrate on Ruby for purposes of this article. Using an object-oriented programming language, we (aspiring) engineers and developers build objects (or things, whichever is easier to understand) by first considering what the intended use is, and then by how it interacts with different objects.

Ok…can I get an example?

Let’s use a hypothetical situation from Avatar: The Last Airbender, when Zuko (“Lee”) and Uncle Iroh (“Mushi”) open a tea shop in Ba Sing Se.

Please excuse how uneven the arrows are. Images are not my own.

You would build a class called Shopkeeper and create the instances “Lee” and “Mushi”. Think of a class as a template — it wouldn’t be very time efficient to create a class for every individual object. These two shopkeepers own a tea shop, the Jasmine Dragon. The Jasmine Dragon is such a success that they have repeat customers. Likewise, you’d create a class Shop with the instance “Jasmine Dragon” and create the class Customer for their many repeat customers. It doesn’t matter if they have 5, 50, or even 500 customers. The shopkeepers know their customers and vice versa, because the tea shop is what links them. In Ruby, these three classes would each be their individual tables, and the tea shop is the single source of truth. They can interact with each other through this source.

What happens if we expand our number of classes?

Previously on Avatar, Aang and his friends travel to Chin Village where they are shocked to discover that not only is the Avatar not welcome, but in a previous life, Avatar Kyoshi allegedly killed their founder, Chin the Conqueror. Aang tries to make amends with the village but his attempts fail to win them over.

In this model, the Avatar and Villager are aware of one another and can interact. PastAvatar is needed, but cannot be accessed.

Eventually, he figures he needs to go directly to the source. Aang turns to Kyoshi, who confirms to both Aang and the villagers that she indirectly killed Chin (or as Kyoshi put it, “a horrible tyrant”), when she split the peninsula from his empire. Avatars Aang and Kyoshi are aware of each other, but the villagers are not aware of Kyoshi. Similarly, Kyoshi is unable to contact the villagers if not for the Avatar connection. The Avatar connection, in this example, is the single source of truth. Without the Avatar connection, Aang would have no way of knowing about Kyoshi’s presence, let alone getting the truth from Kyoshi, nor would Kyoshi be able to access Aang and speak directly to the villagers.

In this model, Past Avatar, Avatar, and Villager are aware of one another because the Avatar Connection exists.

What’s the difference between a join table and a Single Source Of Truth?

SSOT is a concept, and a join table is a method of how we would address relationships or associations in Ruby/Rails, in order to have a Single Source of Truth. There are likely many variations of this across programming languages.

Ok, but I still don’t get why it’s important.

Here are a few reasons why understanding the Single Source of Truth is essential.

  1. Clarity. At some point, the classes in your code need to interact with each other and access certain attributes. As Mulesoft put it, your code and data don’t exist in silos. Understanding SSOT will make it clearer for you as you write your code and build more features. You’ll need to know whether or not to generate a new class or join table based on how your code interacts with what you’re intending to build.
  2. Keeping your code DRY. If you’ve heard it once, you’ve heard it a thousand times. You don’t want repetitive code. Understanding SSOT will help you create methods and even improve your method’s efficiency in their classes so they can build upon one another other. It may not seem like a big deal with the few lines of code you’ve created locally, but imagine the implications when you’re dealing with much bigger batches of information.

Single source of truth can be a confusing concept, especially when you’re starting your coding journey. When in doubt, think about how the classes you’re building interact with one another and if helpful, create or base it on an example (in my case, a story subplot). Even code needs to understand how it relates to one another.

--

--