Fourth Annual DNA Grantees' Workshop
Tuesday, June 24, 2003
MORNING SESSION
Forensic Issues Related to Information Technology
Steve Niezgoda
Biography
MR. NIEZGODA: For the next few minutes I want to talk about some of the unique challenges of this community. The first thing you'll notice with researchers developing software is that this is a very change-averse environment, and there's a reason for that. Sozer: Slide 8
First, imagine for a minute the costs involved in deploying something new in the forensics community or getting something through the court system to the point that it's generally accepted. That takes a significant investment of time and money from the laboratory's resources. Everything needs to be validated. States don't necessarily want to get ahead of everybody else because that exposes them to risks in the legal arena. What you have, then, is a significant investment by a laboratory in a new product. That's why laboratories are reluctant to go do something new. Change is more work, so there has to be a definite value right off the bat to implement something that causes significant change in the laboratory.
Secondly, I think that it's safe to say that the community in general values quality much higher than time to market. Software developers often come from other business domains where time to market is everything: Get the software out and get it out quickly. It's a lot different in the forensic community, for the same reasons we talked about a second ago.
Everything needs to be validated again and again and again. The report that your software produces will be scrutinized in courts. If that report is changed in your next version, you'll be asked, why did that report change, what's different, is this the same, how do you know it's right? Validation, then, becomes critical. Any kind of change needs to be validated so that it can be defensible and admissible in court.
Third, in general, the whole market is maturing. Laboratories have been doing this for a decade plus, and most researchers will come up with a product that plugs into an existing infrastructure. What those products need to do is to interface with other systems that are already there. So many laboratories have information management systems where one instrument will be swapped out and another will be swapped in. It's important for researchers to consider integration, thus building, whenever possible, their software to work with existing interfaces or making sure that the software can be easily dropped in or swapped out later.
Finally, the laboratories also have come to expect high-quality software. One of the classic books about software is Frederick Books' A Mythical Man-Month: Essays on Software Engineering. It's kind of like the bible of scheduling software. It discusses why everything takes so long and why we still haven't figured it out. One of Books' main points is the difference between developing a system that just one person is going to use at their desk and a product that's going to be commercially implemented, which in this case would be 200 laboratories. There's an order of magnitude difference in the effort to develop those two separate software products.
That's a huge point. Some researchers might feel that they're done once the software correctly interfaces with their instrument. But there is a lot more work involved in getting that piece of software to the point where it can be used by the entire forensic community.
In that same vein, a piece of software that will work on one or two samples has to be scaled to support thousands of samples a month in order to prove a concept. So all that needs to be considered in software design.
DR. SOZER: Thank you, Steve.