For one of my cases, I requested architectural diagrams and documentation associated with a particularly complex source code production.

The attorneys were concerned my request implied that my expert analysis would only paraphrase the diagrams and documentation rather than describe the source code. Understandably, they engaged me to read and understand source code. Those attorneys had enough technical background that they could read and understand such diagrams and documentation on their own.

We saw eye-to-eye after I explained that with little to no narrative comments from the authors in the source code itself, it is often more efficient to trace source code when one has a road map to help better understand the terminology, acronyms, and structure that are often described in diagrams and documentation.

However, we did agree that documentation can have one or more of the following flaws:

• Documentation sometimes applies to a version of the product that is different than the produced source code.
• Documentation sometimes contains mistakes such that it does not accurately describe the produced source code.
• Internal documentation sometimes describes intented features that were not implemented in the produced source code.

Even a GPS navigation system can have similar flaws: its map can be outdated, its map can contain errors, and its map can show roads that are currently inaccessible because they are in the process of being repaired. Therefore, looking at the actual road is certainly necessary when driving. 

Likewise, basing one’s expert analysis on the actual source code is necessary, but if the architectural diagrams and documentation for that source code can help better navigate that source code, all the better for the expert’s accuracy and efficiency.