Single Source of Truth…and Why it Matters

Earlier on in my coding journey, if you would have told me I needed to apply an SSOT mindset to my programs I would have said, “Excuse me? I’m just trying to get the tests to pass. (Also, what’s SSOT?)” Which was true at the time. However, now as the bigger picture is becoming clearer, I can begin to see that eventually I’ll be writing code for a multitude of reasons, far beyond just getting some test specs to pass, and one of the biggest reasons will be to make efficient and effective systems and programs. The goal of which can benefit from the implementation of SSOT.

First of all, what is it? The Single Source of Truth concept, in plain English, just means don’t store the same data in more than one place. Why? Other than the fact it’s inefficient to have the same piece of information twice, it opens the door for human error to occur. If a system has the exact same piece of data in two (or three, or four) places in its code, that means if the data needs to be updated, it will also need to be updated in two (or three, or four) places. Which in turn means we’re relying on a human to remember all the places that the same thing needs to be updated. Which we shouldn’t do.

In addition, when talking about relating two objects to each other (for example, relating prospective employees to their multiple job interviewers), these two objects will need to somehow be connected. Instead of having the interviewee remembering all of the people who interviewed them, and each interviewer remembering all of the many candidates they’ve interviewed, a cleaner program would create a separate interviews table to join these two entities where they connect.

Let’s take it from the top. When applying for a software engineering job, an applicant can expect to have multiple rounds of interviews at the same company. Coinciding with this, when a company is looking to hire a software engineer, they can expect to go through many applicants before deciding on one that is a fit for the role. In order to keep track of these many different interviews and applicants, the company could implement a system to keep records of these interactions.

To start, an instance of the Applicants class would be initialized with an applicant’s name and the position for which they’re applying.

Similarly, an instance of the Interviewer class would be initialized with their name and department.

It’s through the Interviews class that we can connect Applicants with Interviewers. An instance of the Interviews class gets initialized with an applicant, an interviewer and an interview time, and all new instances of Interviews get put into the all array, a class variable. Through this, we can hold all of the Applicant-to-Interviewer connections in one place. However, we’ll be able to access them via methods on their respective instances.

Instead of holding all of an instance of Applicants’ Interviewers on that instance, and instead of holding all of an instance of Interviewers’ applicants on that instance, each respective class is given two very useful methods: the interviews method, which allows either instance to iterate through the entire existence of the Interviews class and select just an interview that they participated in, and the applicants/interviewers methods which give the interviewers a list of who their applicants were and the applicants a list of all the people who interviewed them. Both these methods are informed by the all class method on Interviews, which means the actual data only exist in one place.