Explaining Software Development to a Jury

a guide for attorneys and expert witnesses by Philip Greenspun and John Morgan; updated December 2019

In software contract disputes and trade secret cases, the software development process is often an issue. This article is about showing a jury how software development works so that the expert need not rely on telling them. Note that a required piece of scaffolding to enable the jury to understand software development is to explain, with concrete source code examples, what the software being developed looked like.

What to ask for in discovery

Most software projects since the mid-1990s have relied on version control systems, also known as "revision control" or "source control." These keep a keep a record of every file of source code (software authored by a programmer) that is part of a project. For every file, the version control system keeps a record of every version that has ever been "checked in," the date on which the check-in occurred, and the username of the programmer who made the check-in. By inspecting the version control systems "repository," it is possible to see when work was done, what work was done, and by whom work was done.

The comments typed by programmers when checking files into the version control system should be requested separately. These provide a record, usually just one line per check-in, of what the programmer making the update was thinking.

It is also conventional for software developers to use a bug-tracking or issue-tracking system. These will also contain some project history, e.g., what a user requested, which programmer was assigned to handle the request, what was done in response to the request.

Block diagrams or system architecture diagrams should be requested. These will help the jury understand the overall system structure and are more credible than a block diagram created ex post facto by an expert.

See our article on source code review for more tips on discovery.

Demonstrative PowerPoint Slide Presentation

In our experience, judges have always permitted us to use PowerPoint slides as demonstratives with the jury. These are helpful when showing block diagrams, source code fragments, etc., but also help minimize the time that the expert is on the stand, which is important for keeping the jury focussed. The example slides below are from a 2018 software contract case regarding a conventional database-backed Web application.

If a blackboard is available, it is an effective way to break up the slide show and get the expert out and moving in front of the jury. Here is a placeholder slide that reminds the expert what to draw on the blackboard and reminds the jury what they're seeing drawn.

Actual source code enables people in the courtroom to think something that is concrete. A little goes a long way, though. SQL, HTML, and scripting languages can be more amenable to jury presentation than Java and C. Each of the slides below is the basis for a minute or two of discussion from the expert.

Now that the judge and jury have seen what software is, it makes sense to talk about a typical process for developing software.

After these kinds of slides, the structure of the presentation will depend on the type of case. If the case concerns a development project that did not go as planned, some slides presenting the literature on risks in the software development process and ways of mitigating those risks would make sense here.

Now that the jury has a context for (a) what software is, (b) how software is built, (c) what can go right or wrong, the jury is ready to hear about the actual software that is the subject of the lawsuit. Here are some sections that might make sense:

project timeline (humans are accustomed to stories that begin at the beginning and end at the end)
project specifications (what were the programmers told to build?)
system design, e.g., block diagrams and architecture (what the programmers planned to build)
video or screen shots of the software in action (what was built, from a user's perspective)
gross structure, e.g., directories and file/code counts of the as-built source code
fine structure examples, short fragments of source code that illustrate a point
conclusion and recap

Establishing Qualifications and Credentials

The jury needs to understand that the expert is qualified, but on the other hand Tales of a Career in Software Development is unlikely to be the title of an engrossing bestseller. Introductory slides can replace long exchanges of conventional questions and answers regarding the practical experience and academic degrees of the expert. We prefer to lead with work experience so as to avoid the appearance of relying on diplomas alone.

This slide was on the screen for a minute or two while the attorney asked a couple of questions about individual bullet points.

Most software today is built on top of toolkits. Therefore, the next slide establishes the expert's credentials in the toolkit arena:

Finally, it is time to show the degrees:

About the Authors

Philip Greenspun has been a software expert witness since 2005.

John Morgan is a graduate of the Olin College of Engineering and is a working software engineer. He has been doing software expert witness work since 2010.

philg@mit.edu