This is the second of two From the Experts articles examining issues related to computer source code discovery. Read part one here.

The costs associated with computer source code discovery can mount quickly. Experts and code reviewers may be needed to examine and sift through large quantities of code to find the relevant information. Multiple versions of the source code may be at issue. Additionally, if multiple products are involved, the review of multiple source code versions becomes even more complicated. Further, many companies consider source code to be their “crown jewels” and may resist an uncontrolled production of the code. Thus, source code production and review can quickly compound the expense of discovery.

In our previous article we discussed several techniques useful for streamlining source code discovery and containing costs. These techniques ranged from using targeted interrogatories about source code operation to narrowing source code production requests with feature descriptions. Still, even after employing these techniques, efficient investigation may be impeded by misconceptions about the source code and related documents.

This article considers several of these misconceptions and suggests practices to avoid dead ends and unnecessary cost overruns.

1. Educate reviewers on the goals and context

An educated source code reviewer is the greatest source of cost savings. Starting with limited instruction on what to find can lead to countless hours wasted when reviewers inspect irrelevant information. One can provide direction beyond the simple instruction to find a certain function in a number of ways, including providing a defined algorithm description or a summary question set. The attorney/reviewer team should also discuss and, if possible, walk through the product features, review product documentation that describes a product’s features, and study the producing party’s internal information (like design specifications) related to the product.

Some of this investigation may have been completed before the suit or counterclaim was filed, but reviewers may not have been involved in the evaluation. This initial investigation provides important leads for additional review. For example, the information may provide references that software developers likewise used when writing the source code. Software developers may have used descriptive names for algorithm functions or variables that relate to other product documentation. These descriptive terms may be good search terms to use to understand the produced source code.

2. Be cautious of product design documentation