What is Single Source of Truth?
In simple terms, Single Source of Truth is a guideline, which ensures that a team of people or a piece of software would rely on one single source of correct information, which is where the name stems from. In programming, SSOT ensures that the software we design is reliant on the correct and up-to-date information.
To put this to perspective, try to remember that school project you were working on for weeks, which was due in a couple hours. You save the file, find a flash drive, drop it onto it and rush to campus only to find out that your “important_doc_3_complete_done_final_2” was the amount of work you had saved a few nights ago. And at that point not only do you have to explain yourself to your teacher, but try and dig out the latest version of the project from dozens of files with similar names (and pray that the file wasn’t saved anywhere outside the desktop).
Memories aside, what happened, was a simplified version of what a large amount of companies struggle with and why IT and data optimisation services exist. The lack of SSOT can be catastrophic for data driven environments. A good example by Forbes describes how a lack of SSOT can negatively impact huge teams and future business strategies when lack of a single confirmed source of data creates biases and data manipulation, makes human error a frequent occurrence and puts an entire corporation to a disadvantage against their competitors.
SSOT and reference in software development
Each time you send a message to your friend over Messenger, your conversation gets stored somewhere on Facebook’s server and if you try to access the chat history, your computer sends a request to the server to access that one SSOT which is your conversation so you are both seeing the same conversation. Your browser refers you to the conversation history.
During our careers as software engineers we will come across such problems numerous times and it is important to understand the concept so we can avoid a lot of continuity problems with our code. In object oriented programming languages object relationships like “has many through” and “belongs to” are implemented to ensure that when we try to access or manipulate the stored information, it is updated properly and after that every entity, be that a function, a user or another program would be able to locate the correct information. As of now, the majority of relevant programming languages have frameworks and libraries that take care of that for us, however it is crucial to understand what’s going on in order to be able to troubleshoot our code and to be able to adapt to the requirements, should that become necessary.
So how do we do locate the correct information in our software? We create references. Instead of having our data in multiple copies and exist in multiple places, we use certain principles to let our functions know, where to locate the piece of information it requires. Similarly to desktop shortcuts, we access the required information indirectly using tools other than just digging our way to the information we need.
Example of an object relationship
Imagine yourself being a client in bank. You can be one of thousands of a bank’s clients and you can be dealing with one of hundreds of the bank’s workers. You walk to one of the tills where you are greeted by one of the workers and you see a small display of your financial status (for the sake of this explanation let’s ignore the security flaws behind such a model). The screen shows you your bank status and the worker’s name. The clerk can see your bank info and your name. Let’s define that in Ruby:
We now have a Class for the 3 objects participating in the conversation — for the client, the bank clerk and the client’s bank account. The SSOT in this case, obviously, is the BankAccount class, which we will call a join.
Now that we have the definitions for the classes, let’s create a couple instances.
We have created an instance of each of the 3 classes. Now we can write functions that will be able to access the information “on the other end” through our single source of truth. Let’s pry our file and run it in the console.
Now, for Jessica to see Steve’s name, we need to define a method. Let’s call it current_client_name.
Running jess.current_client_name in the console provides us with all the instance information
As you can see, we are able to access Jessica’s current client’s information without explicitly programming it anywhere or giving Jessica any special form of access. By associating the bank account with both the clerk and the client, they can see each other’s information through the one single source of truth that is the client’s bank account information. Similarly, Steve will be able to see the Clerk’s name on the screen even if Jessica forgot her badge at home today:
Additional convenience
If Steve ever decides to change his name, legally he will have to inform the bank. Similarly Jessica finds herself unsatisfied with her name she will need to inform her employer (the bank) once she changes it and the bank account instance would be updated “automatically”:
Running the file in the console and entering the name changing commands affects our bank account instance:
Closing remarks
As convenient as it seems to store all the information in one place, sometimes it doesn’t have to be gathered in the join class. For instance, even after changing names, our friends should be aware of the updated info without making all the way to the bank:
Additionally, information can be scattered around different databases, classes can have highly complex relationships and that doesn’t even account for multiple users/programs trying to access/override the same information.
Conclusion: The SSOT is an important principle not only in Ruby-on-Rails, but in any programming language, data driven organisation. It is crucial to have a decent understanding of the principle when creating an application if we want to build a robust, versatile and flexible program.
