Site Home : Software : one article
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.
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:
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:
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.