Archives – April, 2016

Texas Lawyer: 13 Must-Ask Questions Before Enlisting An Expert Witness

Originally published in Texas Lawyer, an ALM Media publication, April 20, 2016

*Part of the ALM family of award-winning legal products and publications.*

By: Quentin Brogdon

Expert witnesses can make or break a case. Trial lawyers thoroughly investigate opposing experts, but often fail to subject their own experts to that same high level of scrutiny. The consequence of hiring the wrong expert can include the striking of the expert, sanctions, massive wasted financial resources, and even the dismissal of a party’s claims or defenses. When it comes to hiring experts, an ounce of prevention is worth a pound of cure.

First, determine whether the headache of dealing with an expert is really needed. Even if experts are allowed to opine about an issue, you may not want to hire an expert if expert testimony is not required. The decision not to hire an expert may be based on considerations of expense, the potential for the expert to contradict other experts or fact witnesses, or a concern that the jury may not find testimony from a hired expert on the particular issue to be persuasive or credible.

Some issues generally are inappropriate for expert testimony. Texas courts have prevented experts from testifying about: 1. pure questions of law; 2. mixed questions of fact and law, if not confined to relevant issues and based on the proper legal standard; 3. subjects within the jurors’ common knowledge; 4. the truthfulness of a witness; 5. whether conduct is outrageous; and 6. the dollar value of love and affection.

If you must hire an expert, you can avoid much future aggravation by running from experts who: 1. act unethically; 2. have problems communicating; 3. have been struck by other courts; 4. have a criminal or disciplinary history; 5. have taken prior inconsistent positions under oath or in publications; 6. have only expressed opinions in the context of litigation; 7. have inappropriate internet postings by, or about them; 8. have promised expertise in an unrealistic number of different areas; 9. are evasive about case budgets or tasks to be performed; 10. are unwilling to comply with your guidance about their role in the case; 11. brag about verdicts they enabled or prevented through their brilliant testimony and expertise, 12. send spontaneous, ill-advised emails at every stage of their thought processes, 13. demand that you immediately file a motion to modify the scheduling order’s expert report deadline to fit their busy schedule; 14. make “promise the moon” statements, such as “I’m going to win this for you;” or 15. try to act as a lawyer or delve into settlement discussions or case strategy.

If possible, it is best to meet the expert before hiring him to assess first-hand how the expert carries himself. Is he able to make eye contact when speaking? Does he appear to be credible and persuasive? Can he teach the judge and the jurors by reducing complex concepts to understandable basics?

You can get answers to the hard questions during the initial interview of the expert, or you can hear the answers for the first time during the expert’s deposition. During the interview of the expert, ask pointed questions, such as:

1. “Are you the best expert for this issue?” Given a chance, credible experts who appear to be a perfect fit often will confess that they are not the right expert, and that another expert or another type of expert would be a better fit.

2. “What in your background, experience, and training enables you to express opinions about this issue?” A qualified expert cannot help if he cannot sell the judge and jurors on his qualifications. Think long and hard before you hire any expert who cannot even sell you on his qualifications.

3. “Have you ever been prevented from testifying in any case by a court for any reason?” If the answer is yes, ask for case styles, attorneys, and reasons that the expert was prevented from testifying.

4. “Do you anticipate any problem in getting your report done before the expert designation deadline?” If there is a problem, you want to know about it now, not on the eve of the deadline.

5. “What testimony, documents, and information will you need to formulate and support your opinions in this case?” Let the expert tell you before he is hired what discovery you need to undertake to support and bolster his opinions. Do not allow the expert to get struck simply because you did not complete the underlying discovery necessary to support his opinions. Likewise, you need to know at the outset if the expert has unreasonable or impossible expectations.

6. “Have you ever testified for or against the opposing party before?” If the other side is familiar with your expert, you want to know that now.

7. Ask about publications, prior testimony, internet references, speaking engagements,

advertisements, membership in professional organizations, criminal and disciplinary history, and past representations about areas of expertise.

8. “Are there other types of experts with whom you typically work on these types of cases?” You may be speaking to only part of an expert team—all of whom are indispensable.

9. Ask pointed Daubert-based questions about: 1. testing of the expert’s theory; 2. the theory’s potential rate of error; 3. whether the theory has been, or could be subjected to peer review; 4. whether the theory has been generally accepted as valid by the scientific community; 5. the extent to which the theory relies on the subjective interpretation of the expert; and 6. the non-judicial uses that have been made of the theory.

10. Ask about previous testifying experience, including case

styles, outcomes of cases, names of hiring and opposing attorneys, Daubert strikes granted, cases against your opponent, ratio of plaintiffs’ to defense work, and ratio

of litigation consulting work to other types of work.

11. Explain that you expect to hear any and all misgivings about the case, up front, and that you are not looking for an outcome-oriented review. You do not want to learn for the first time during your over-eager expert’s deposition that he has serious misgivings about your case.

12. Ask about the expert’s experience with the opposing side’s experts and his opinion of them. If the opposing side has hired your expert’s best friend, mentor, or former employer, you need to know that now. Likewise, if your expert seems intimidated by the names or credentials of the other side’s experts, you may want to consider hiring a different expert.

13. Ask how your expert prefers to receive documents and communications. Some experts prefer everything in electronic format, while others still want everything in paper format. If an expert cannot, or will not review paper or electronic documents, you need to know that now.

If you do find the right expert, do not set up the expert to fail after you hire him. Promptly notify him of deadlines for expert reports, Daubert hearings, trials, and other relevant activities in the case, and periodically remind him of forthcoming deadlines.

In dealing with experts, an ounce of prevention really is worth a pound of cure.

Quentin Brogdon is a partner with Crain Lewis Brogdon in Dallas. He is board certified in personal-injury trial law by the Texas Board of Legal Specialization and in civil trial advocacy by the National Board of Trial Advocacy, and he is the vice president of the Dallas Chapter of the American Board of Trial Advocates. His email is

Original Source:

Leave a Comment April 26, 2016

The Importance of Source Code Analysis for Investigations (Part 1)

Originally pushed for Legaltech News, an ALM publication

October 28, 2015

by Joe Sremack, an ALM Listing Expert

Source code analysis can provide critical insights needed to solve an investigation and answer key questions about how events occurred.


Source code analysis is a powerful tool that can answer questions that traditional investigative methods such as document review and data analysis cannot. Traditional methods answer questions about the whowhatwherewhen, and why of a matter, but may not fully answer how certain events occurred. Source code can be found within any organization, and many organizations are increasingly reliant on creating and customizing their own software. Source code analysis can provide critical insights needed to solve an investigation and answer key questions about how events occurred.

In Part 1 of this two-part series, Joe Sremack discusses the role of source code analysis for investigations.

What is source code?

Source code is a set of computer instructions written in a human-readable form. It is a set of text-based instructions written in a programming language, compiled or interpreted to perform one or more tasks, and the source code statements follow the programming language’s syntax and semantics rules. There are hundreds of known programming languages—thousands if you count obscure and task-specific languages—used for different purposes and with their own syntaxes and semantics. Once source code is written, it can be executed either by being compiled into an executable program or at runtime by an interpreter that translates the code into computer operations.

The format of source code depends on the language and Integrated Development Environment (IDE) used. Some source code is simply one or more text files. This is commonly the case for scripting languages, such as Python and Ruby. Other source code can combine text files and non-text file objects—such as pre-compiled libraries, GUI design files, and system configuration files. Compiled languages often have these non-text objects, which are combined in an IDE. Analyzing the text file–only source code can be accomplished with any text editor, but the non-text file objects may require specialized software to view.

Source code is as varied as the different types of software. Source code can be written for mainframe computers, personal desktop and laptops, servers, virtual environments, websites, business intelligence platforms, data transfer processes, data-centric mobile applications, and so on. Each environment can have a host of different types of software created for it—each with different programming languages. The source code for each can be analyzed to answer questions about how the software operated and what was performed.

Source code can be created by various people in different roles. Because code comes in many different forms, it is not only created by software developers and specialized programmers. While highly specialized, complex software may only be created by programmers, other types of source code can be created by people in different roles. Database queries, small scripts, and batch programs can all be created with relatively little programming knowledge or experience. This is important for investigations, because the investigator needs to consider who could potentially write source code and the types of programs that could be written. For example, an employee in a company’s payroll department may create logic using Excel VBA to generate ghost employee records that could be critical to the investigation.

Why analyze source code?

Source code is valuable for investigations for a number of reasons. First, source code contains information about the logic and business rules used to perform various operations. The operations of an organization may be described or documented, but those may not match the actual operations. Source code can be used to reveal the actual operations. For example, a healthcare company may claim that it does not modify certain types of medical records. If it relies on custom software for its medical record processing, that claim can be tested by reviewing the medical record processing software’s source code.

Second, the source code for key business operations contains information about the location and nature of the data used for specific operations. In an adversarial investigation, an investigator can locate key data repositories via the source code, rather than simply relying on potentially deceptive interview subjects. This enables an investigator to identify key data sources more completely and effectively.

Third, source code can be used to aid the data analysis process. The investigator can use the logic from the source code to determine the types of data to analyze and uncover relationships between various data sets. These insights can be used to understand business rules and help identify critical elements in the data that might otherwise go unnoticed.

Fourth, source code can be analyzed in relation to the data to identify discrepancies. Source code analysis can yield insights into the business rules for how the data should be stored. If an investigator is confident that data should not have been modified by anything except for that program, the data can be tested in relation to the business rules in the source code to identify anomalies. These anomalies, in turn, may point to non-standard or fraudulent activity performed outside of the business rules.

Other examples of goals for source code analysis include:

  • Analyzing similarities and differences between two sets of source code as part of an intellectual property dispute
  • Analyzing how a program’s behavior evolved over time
  • Locating security flaws


Investigators should consider source code when conducting investigations. Numerous forms of source code can exist, and since many organizations have customized software that performs business operations, the source code may be a valuable source of information. Source code analysis can help validate data analysis, identify data sources, pinpoint data anomalies and fraudulent activity, or highlight how a data breach occurred. Without source code analysis, the investigator may not have a full understanding of what actually happened.

Original Source:


Part 2 of the series, covering the types of source code analysis that can be performed and how you can integrate source code analysis into an investigation, can be found on

Leave a Comment April 8, 2016


Phone: 888-809-0133


Expert Witnesses

ALM Experts Blog