The problem with a traditional approach to development is that facts, which are always true about the idea being developed, end up being continuously recalculated in each context where that fact is needed, because it isn't just written down once at the beginning.
If we take the time to write down once, in a machine queryable format, then we can query those details, calculate, and write down those facts which are going to be true in every technical context, once. That’s why it’s called a Single Source of Truth.
Let’s take an example where a 3 character ID value is embedded inside of a longer string of text, starting an Index 5. To extract that value you would take the substring with characters [5..7].
Original String: “01234567890123456789”
ID = 567
The value 7 is computed by adding the starting index 5 + the length of the parameter being extracted, but because of the "Fence Post Situation" the developer has to remember to remove 1 to correctly get the ending index.
StartingIndex = 5
Length = 3
EndingIndex = StartIndex + Length - 1
^
Problem
This value must be recomputed, at runtime, on every platform ... correctly!
Consider however, that in fact EndingIndex = 7 is always going to be true. It’s going to be true in Android, iOS, Windows, Web, Front-End, Back-End, Documentation, Testing. The ending index is always 7 - as long as the starting index is 5 and the length is 3.
So why does this value typically need to be constantly recomputed at runtime? Because it doesn’t usually get computed and written down once, at design time.
So - when that starting index is set, and the length is set - a Single Source of Truth can re-calculate the Ending Index once - at design time, before a single line of code has been written, and then shared liberally with all of the tech which needs it.
Because those indexes are not going to change, unless the length changes. Those are things which can be calculated once, at design time, and written down and then shared among every technical context that might need to parse that string. And since it was just calculated once, and then written down, now it never has to be recomputed, or even understood in all of the places that might need to interact with those numbers. Every technical context can just take that section of the string and that is going to be the appropriate part of the string for its parameter value. This has the effect of simplifying the logic in all of the downstream tech which is going to interact with this technology.
If we don't do that work once, upfront, then every time that string needs to be parsed, the ending index based on the starting index and length has to be recomputed.
It has to be recomputed in Android … correctly.
It has to be reproduced accurately in Swift for iOS,.
The Web app has to also accurately recalculate this value.
And each of these contexts is an opportunity for one or more of them to do it wrong. And when that happens, it introduces a bug. So now we must rigorously test all of the code, in order to find that bug. Additionally, every time that length changes, the starting and ending index that the length influences have to be updated and they have to be typically updated in the Android, and the iOS, and the Web app, and the unit tests.
Because in all those places the code, which compute the ending index based on the length = 3, is considered to be “source code”. This is true even though it clearly isn't the source of that length - which will change whenever we change the length of the parameter at the specification level of the project.
That happens once at design time and we could, if we had a single source of truth, just compute that new ending index once, and then write it down.
And now the new ending index can be shared with any platform that needs to parse that string. All they need to do is take the start index through the ending index and they will get the right value.
