Twenty-seven
years of experience in software design, telecommunications
and Internet technology, including computer graphics; computer
networks and gaming; computer-telephony integration, telecom
business software and VoIP; Internet publishing, e-commerce
and B2B.
Companies worked for include Digital Equipment Corp.,
GTE/Verizon, Utility Partners, Tanning Technology and
Evatone.
Expert witness in more than 20 cases, including software-vendor
disputes, patent litigation, patent evaluation, electronic
discovery, computer forensics and Internet copyright.
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.
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."
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.
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.
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.
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 it 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.
IMS Expert Services is the premier expert
witness and litigation consultant search firm in the legal industry.
IMS is focused exclusively on providing custom expert
witness search services. We are proud to be the choice of over
90 of the AmLaw Top 100, half of the Fortune 100, and you. Call us
at 877-838-8464.