The Trouble with Tracing: Traceability Dissected

the drudgery of complex information, structure, and linkages, and also report, navigate, and examine the results. These are what answer the questions we want to know such as: What’s in this build? What’s the status of this change? What went into this change? Where did this bug come from?

One Ultimate Mission – Fostering a Community of Trust
Economists talk about measuring the level of trust in a society. It's been proven that societies where there is greater trust experience faster economic growth—"My word is my bond." The same is true in software. To have trust, you must not be afraid that someone is hiding something from you. Transparency enhances trust.

All of the things we have discussed so far distill down to this: they help convey to us (the stakeholders) a greater confidence in our knowledge of what is going on in the project, and whether or not it will successfully deliver what we need, when we need it. This let’s us trust the people managing and performing the work.

All of the traceability questions we asked and the reasons we gave all boil down to questions of trust, and communication:

• Do I trust the analysts/architects to do what I said and say what they did?

• Do I trust the product or its producers to correctly realize the correct requirements?

• Do I trust the process or the engineers following it?

• Do I trust the project or the people managing it?

• Do I trust the environment in which it is built and tested?
• Do I trust the organization to be able to remember what they learned and learn from their mistakes?

Traceability, Transparency, and Trust
Whether or not traceability efforts successfully achieve any of these goals is another matter entirely. Often, traceability efforts achieve at most one of these (conformance), and sometimes not even that. Many question whether the amount of effort required actually adds more value than what it subtracts in terms of effort (particularly when traceability efforts themselves may create additional artifacts and activities that require tracing).

Traceability is often desired because it's presumed to somehow alleviate fears and give us "TRUST-ability." I suspect that's really an illusion. Traceability is useful to the extent that it facilitates more effective communication & interaction between individuals, teams, and stakeholders. And traceability can be useful to the extent that its helps us successfully convey, codify and validate system knowledge.

So to the extent that traceability helps us more quickly identify the right people to interact with and the right information to initiate that interaction, it can be extremely useful. It is the people and the quality of their interactions that provide the desired "trustability." Beyond that, unless unobtrusively automated, it can quickly turn into "busy work" with very high "friction" on development of new functionality realized as "working software."

Trustability ultimately has to come from "people." And while transparency engenders trust, traceability is effective toward the goal of trustability only to the extent it facilitates transparency and communication.

We need to move the industry to a place where software development is not an opaque cloud where magic happens (maybe).

Management can believe that all reports are lies or hiding the truth or they can know that reports are automatically generated based on transparent traceability data. This leads them to trust the information in the reports and to trust the teams generating them. It is this principle that was at the heart of FDD knowledge base systems and is a major goal for Microsoft’s new Visual Studio Team System.

Communication is increased by trust, but also generates other requirements. Managers usually can't