The maths behind "single source of truth"
Venduco is a strong proponent of setting up systems that support efficient, timely communication about software quality.
This is because communication increasingly becomes one of the major impediments to software quality and release velocity - as the team grows.
This graph shows, for one person, you have zero lines of communication and little need for overhead.
With 2, just 2 paths, With 3, 3 paths. Linear. No problem.
But when your team gets to 4 people, now you have 6 possible communication paths among you. And the number of paths continue to grow as the organisation gets larger and larger.
This graph is very familiar to software developers - its the same graph to explain how many side effects code could have. Just as the goal of reducing dependencies makes code more maintainable, so reducing the number of communication connections in an organisation can simplify decision making.
The role of bug tracking, task tracking, document management, and QA systems in an organisation is to give a single source of truth about the state of the software development.
I have been amazed about how much easier it is in a meeting to have everyone around the table arguing about what to do about trusted data projected on the screen, compared to a meeting where everyone brings their own data set.
In terms of our dependency graph, a single source of truth means all decision makers are connected to the same status data, and not discussing everything with every other person.
The goals of this single source of truth:
Everyone in the organisation agrees that this is the single source of truth. If it contains incorrect information, the source of truth must be updated. There are not personal "sources of truth".Contains information about all aspects of the software project, especially interfaces to other organisations.It should not take much effort to keep it up to date, so it is always up to date. When possible, the information should be updated automatically.It should be updated by the person closest to that information so it is as accurate as possible.
In software, single source of truth is the source code itself. But source code is quite opaque to non-developers. A well designed bug tracking system and process maps the developer world of source code to the tester/customer/manager view of changes and requirements. The mapping is key. The trustworthiness of the bug tracking system is enhanced if every source code change correlates with a change tracked in the bug tracking system.