Thorough preparation for hostile supervised source code review, deposition and testimony is vital. The best way for an expert witness to prepare is to over-prepare. Competent experts prepare until they get it right.
Excellent experts prepare until they cannot get it wrong.
“Moderation is a fatal thing, Lady Hunstanton. Nothing succeeds like excess.”
– Oscar Wilde, from A Woman of No Importance, Act 3 (1893).
This article explains how the above quotation is relevant to an expert witness.
My experience as an expert has been that for many of my cases, most of my time is spent preparing for interactions with the other side. My reports are written as a series of drafts that I share with the attorneys that I work with. We discuss the material, and that allows me opportunities to clarify exactly what I mean. The best attorneys that I have worked with have typically challenged the material as it evolves. My responses often get incorporated into the next draft.
As I work through each draft of a report, if there is material that is never the subject of discussion, I must ask myself if that material is fundamental and obvious, or whether it provides a basis for my opinions. Since an expert report concludes with opinions, material that is not fundamental, or necessary background, and is not something that was relied on to form an opinion, might not be germane enough to include in the report.
As a motivating principle, if one views each statement in a report as a potential attack vector that might be exploited by the opposing side, then it follows that removing unnecessary statements makes for a stronger report. This is why a vigorous dialog between an expert and the attorneys that they work with will, in general, yield a better result.
To date, my most common types of interactions with the opposition have been:
This article explains the type of preparation I do for these circumstances.
Computer source code has been the most common type of restricted material that I have reviewed to date. Project-related information is often not as closely guarded. I wrote about how I do source code comparisons previously. This article will not repeat that information.
A software expert who needs to examine source code would ideally like complete access to the material, in their office. They would like to use special software and/or hardware to analyze the material, and they might want to write scripts (small programs) to help them with their task. Sometimes this is possible. Sometimes this is not.
The restrictions on how and where I, as an expert, can examine source code can be profound. I find that imposing these restrictions seriously impacts what can be accomplished, and how the source code review can be approached. They also raise the cost of litigation for plaintiff and defendant significantly; it would be much cheaper for both parties if they would just allow the software expert access to any tools they want. A good expert will eventually find out the facts one way or another anyway, so why waste money? The cost penalty paid by both sides for imposing tight restrictions on experts can quickly run into 5 or 6 figures. The extra cost comes from extra time spent preparing, and, if permitted by the court, extra time examining evidence with reduced efficiency.
Restricted materials are sometimes provided to an expert in a glass-walled evidence room (sometimes this is called a ‘clean room’), and if they are placed in such a room then the expert is usually observed the entire time, they review the material. Normally, at least one representative of the opposing counsel’s firm observes the expert the entire time that the expert has access to the restricted material. The evidence room usually has no communication devices, and the expert may not bring in a mobile device, camera, etc. A limited amount of Bates-numbered paper is usually provided for the expert to take notes.
It is not unusual for opposing counsel to be unhelpful. Sometimes, however, opposing counsel crosses the line into unprofessional hostility. While attorneys are expected to be partisan, they are prohibited from tampering with evidence. Sometimes, when their desire not to lose a weak case overcomes their better judgment, they cross the line because they think they can get away with it.
A case that I worked on required me to compare two bodies of code. One body of code came from my client, and I could inspect it at leisure on my laptop over many weeks. The other body of code came from the opposition.
Before providing access to the source code, opposing counsel misrepresented the computer language it in which it was written and the software frameworks that were used. Fortunately, I did not put my faith in the information the opposition provided, and instead I spent quite a lot of time writing scripts to identify unique aspects of my client’s code. I prepared 250 pages of instructions for myself to follow while in the glass-walled evidence room, for various possible scenarios. Armed with these instructions, I quickly discovered exactly which portions of source code were similar between the opposition’s evidence and our side’s evidence.
Every day that I spent in the glass evidence room examining the opposition’s code I found that the evidence had been changed significantly. Directories had reorganized, new directories had been added, and others had been removed. That did not slow me down much due to the nearly fanatical amount of preparation I had done. I knew what to look for and found it. All the opposition’s shenanigans did not help their case — in fact the judge was not impressed because I chronicled the events in my report. It was satisfying for me to be able to voice strong opinions in my report, backed up by incontrovertible evidence and straightforward reasoning.
The extra cost of the unusual amount of preparation I did for this case was significant. The only reason I felt it necessary to dedicate such an extreme amount of time to preparing was because opposing counsel had previously demonstrated a willingness to exceed proper behavior. Each transgression motivated further transgressions. The risk that they assumed was that, if they lost, and the judge found they violated legal standards, they might be subject to consequences.
It is not enough for an expert to know the facts, perform appropriate analysis and provide defensible opinions. Answering questions simply, directly and without embellishment can be surprisingly difficult. Getting it right under pressure, while tired from travel and long days of work, requires extensive practice.
Preparation for testimony begins with the first draft of my report and includes rehearsals with the attorneys I work with.
Following is a typical sequence of events before my report is submitted. This explanation is rather general and approximates what might be done in US Federal court and ITC arbitration. Patent-related matters do not necessarily follow this sequence exactly as described; however, those sequences are similar enough that this general description should be instructive for those who have not gone through these types of legal processes before.
My report is written with the intention of effectively defending it:
After my report is submitted to the court, and the other side has responded, the sequence generally continues as follows:
I want to make a distinction between rote memorization and being able to recall all the salient points of my expert report easily, and to discuss their subtleties in detail. If an expert is viewed as a puppet because they stick verbatim to a script, then their credibility is lost. On the other hand, being able to readily articulate a nuanced understanding of the details of a case is impressive. “Threading the needle” by not falling into technobabble and plainly stating facts, methodology and opinions without being boring can be quite a challenge.
Being visibly relaxed and confident while easily handling whatever the other side brings forward goes a long way to winning as an expert. (Please remember that my definition of ‘winning’ may not be what you might expect.)
Confidence comes from knowing that one simply cannot make a mistake. The right words, demeanor and sense of timing have been habituated into the unconscious. Excellence has become natural.
Michael Slinn is an active software industry technologist and executive with 45 years of experience. He has written 3 books on distributed computing and has taught in university, community college and commercially. He has been accepted as a software expert witness in US Federal courts and in the International Court of Arbitration of the International Chamber of Commerce in Paris, France. For more than 20 years Mr. Slinn as provided expert testimony under oath at trial, for hearings, and for depositions. The scope of his engagements include opining and providing declarations regarding hardware and software patents, commercial disputes and trade secret litigation matters.
Clinical coding is the analysis of clinical statements for the purpose of assigning standard codes through a classification system. This process is a critical piece of health information management and is carried out by a health information professional. Our coding experts have worked as professors, consultants, clinical coders, medical record technicians, diagnostic coders, clinical coding officers, and nosologists.
Computers have revolutionized nearly every field of expertise allowing practitioners to gather, organize, visualize, assess, and act on data as never before — each of these developments becoming its own industry. Our computer experts have been retained due to their deep knowledge and experience working as electrical engineers, software engineers, programmers, professors, IP consultants, and more.