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
This content has been archived. It is available through our partners, LexisNexis® and Bloomberg Law.
To view this content, please continue to their sites.
Not a Lexis Subscriber?
Subscribe Now
Not a Bloomberg Law Subscriber?
Subscribe Now
LexisNexis® and Bloomberg Law are third party online distributors of the broad collection of current and archived versions of ALM's legal news publications. LexisNexis® and Bloomberg Law customers are able to access and use ALM's content, including content from the National Law Journal, The American Lawyer, Legaltech News, The New York Law Journal, and Corporate Counsel, as well as other sources of legal information.
For questions call 1-877-256-2472 or contact us at [email protected]