Clearing Up Software Myths for Attorneys

Robert Ambrogi, Editor of IMS ExpertServices' BullsEye Newsletter

This article was originally published in BullsEye, a newsletter distributed by IMS ExpertServices. IMS ExpertServices is the premier expert witness and litigation consultant search firm in the legal industry, focused exclusively on providing custom expert witness searches to attorneys. Please visit IMS ExpertServices at www.ims-expertservices.com or call us at 877-838-8464.

5 June 2008. Lawyers' grasp of computer software technology falls along a broad spectrum, but the lawyers at either extreme - those who are either well versed in software or virtually ignorant about it - can be equally dangerous when it comes to working with an expert witness.

At one extreme, lawyers who are trained in technology sometimes confuse their academic knowledge with the actual practices in the industry, leading to misunderstandings and even disagreements with the expert, explains Ivan Zatkovich, an expert in software design, telecommunications and Internet technology.

At the other extreme, lawyers who know almost nothing can make it difficult for the expert to create a plan for how best to evaluate the case and focus his time.

Whatever a lawyer's degree of knowledge, Zatkovich strives to help his clients break through common misperceptions and reveal the reality of how software works. In litigation, this breakthrough often proves to be the key in getting to the heart of the case.

Software Developers Share A Secret Code

A lawyer once asked Zatkovich to provide quotations from the "software bible" to show that the defendant was not using standard practices for disk backups and that its systems were not designed to industry standards. When Zatkovich explained that there is no such bible, the lawyer told him not to worry, because he would "keep it a secret too."

The truth is that the software industry uses a variety of dictionaries and acronym guides, Zatkovich says, but most are of little help in answering questions that turn on industry practices, context and experience. For example, in a software contract, the terms "update," "upgrade" and "enhancement" can carry much different meanings, but those differences would not be defined in any industry dictionary.

Along the same lines, software developers use many different methodologies and practices. One may describe a "waterfall" approach, another a RAD (rapid application development) approach. "The guide should be not what methodology is used," Zatkovich notes, "but how it is used."

Myth: Data Discovery Is Daunting

In the area of e-discovery, lawyers have two common misconceptions. The first is that the sheer volume of data a company retains makes it difficult to find pertinent discovery material. The second is that the ease by which a file can be deleted makes it easy to lose documents accidentally or erase them intentionally.

As to volume, the reality is that electronic documents are much easier to find than their paper counterparts. This is so because of the many methods built into computers for storing, tagging, searching, copying and backing-up files.

For much the same reason, it is extremely difficult to lose or even erase all traces of a file once it is created. "Many deleted files can be recovered," Zatkovich explains. "And even unrecoverable files leave traces that they existed at one time."

Zatkovich recalls a case in which he was brought in to search a computer for examples of fraudulent contracts, only to find the computer's owner had deleted the files and wiped the disk clean. With a bit of detective work, he was able to find an image of the disk created during a routine back-up and recover deleted versions of the contracts.

Myth: Software Failures Are Usually Technical

In disputes with software vendors, lawyers often assume that software failures are due to technical problems or lack of technical skill. In fact, the most common causes of failure in software projects are not technical.

The reality is that such projects more commonly fail as the result of poor project management or overzealous sales. This may be the fault of a client who keeps adding requirements to the project - what Zatkovich calls "scope creep." Or it may be the fault of the vendor, either in failing to manage the project during development or in overselling the product and setting unreasonable expectations.

Zatkovich points to a case in which he was retained to analyze software that was performing so poorly as to be unusable. The attorney assumed that the problem was either in the technology or in the vendor's lack of technical skills.

The truth lay elsewhere, Zatkovich discovered. The vendor had deployed the software successfully in another industry, he learned, so the problem was not either technology or skill.

Rather, the problem was that the software was now being jury-rigged to use in a much-different industry. The client kept adding requirements that made the software bloated and more complex, and the vendor lacked sufficient familiarity with the industry to assess and weigh the client's added requirements.

Myth: Theft Of Computer Code Is Common

A myth common among lawyers in trade-secrets matters is that designers and developers actively borrow or steal one another's code because it is so easy to do. The reality, Zatkovich says, is that most code developed today is not so portable that it can be copied from one application and pasted into another.

The perception of theft is due as much to the speed at which ideas spread as to any actual copying or reengineering. Zatkovich recalls his own experience with this while working for Digital Equipment in the early 1980s.

He attended a demonstration by Xerox of a prototype called the Xerox Star. It replaced typed commands with something called a "mouse" used to point and click on buttons on the screen. He went straight back to his boss and insisted Digital start building something similar.

"I wasn't thinking, 'Let's steal this idea so we can market it ourselves,'" he explained. "I simply knew that this was the right way to build software."

Turns out Apple's Steve Jobs had seen the same demo and likewise thought to build something similar. It was not long before Bill Gates had the same light bulb go off.

"Bottom line is that when most developers see a really good idea, they can't imagine building a product without that new idea," Zatkovich says. Myth: Software Function Equals Software Structure

With software patents, lawyers often believe that it is difficult to tell the difference between a general concept in the industry and a specific idea that is intellectual property. Software is so easy to copy and so generic in structure that it is difficult to link to a particular patent, they think.

The reality is that while ideas spread easily within the software industry, the actual code is rarely copied from one application to another. Moreover, a particular function can be implemented in many different ways in software. Each of those ways would have a specific algorithm and structure. This makes is possible to determine if one software product's algorithm or structure is equivalent to another's.

A key consequence of these misconceptions has been the lack of predictability and uniformity in software patent litigation. "I have been involved in cases where system patents identified very good ideas but provided very limited specifications and claim language other than indicating a 'computer' and 'software' as the structure."

Zatkovich enjoys helping lawyers understand computer software, no matter where they fall on the spectrum of technological proficiency. But given the extremes of lawyers who are highly knowledgeable and those who are virtually clueless, he prefers lawyers who fall somewhere in the middle. "They are the easiest to work with," he says.

Robert J. Ambrogi is a lawyer and media consultant in Rockport, Mass. He writes the blog LawSites, www.legaline.com/lawsites.html