As a developer, do you understand the legal meaning behind this concept? If you don't, it simply means you haven't been sued yet.

Y2K: Setting the Standard for Care

As a developer, do you understand the legal meaning behind this concept? If you don't, it simply means you haven't been sued yet.

• By John Ellsworth
• 03/01/1999

Do you have what it takes to be successfully sued for your Y2K efforts?

I’m a programmer and a lawyer. In the past I’ve sued people and companies for negligence of all kinds. Today, however, my life is much more peaceful; I work full-time as a software programmer.

My present consulting efforts are directed toward Y2K remediation on a commercial program written in Visual Basic 3. The program is far from object-oriented, is nebulous, and was written by a group who seemed bent on writing largely uncommented code. In short, it’s the kind of code most everyone involved in these efforts must deal with on a daily basis. It’s not fun, but it can be challenging—and it taxes our skills.

In the February issue of MCP Magazine, Harry Brelsford wrote a column titled, "Y2K and the Law." This excellent article addressed the protection of Y2K remediators. Harry stressed the importance of the legal language contained in remediation contracts, and of obtaining adequate malpractice insurance.

My effort introduces you to the bottom line legal issue of the "Standard of Care." If not understood and addressed by developers involved in Y2K efforts, Standard of Care is the legal phaser that could blast them out of business.

What’s Standard of Care?

If you aren’t aware of Standard of Care already, it’s likely you’re one of the blessed who’s never been sued for professional negligence. If you had been sued, you would know how these cases revolve around Standard of Care like your software projects revolve (at least to some extent) around use-cases.

Let’s look at the legal lingo here. Like programming languages, law has a vocabulary and syntax all its own. It’s not difficult, but, like any good programming language, there’s a time to insert a brace ({) and a time to leave it out.

Lesson 1. What Courts Mean by Standard of Care

Broadly speaking, Standard of Care is what other professionals in the same profession do to obtain a satisfactory result for their client or patient. For the doctor delivering a baby, this could mean a clean operating room, a complete and sufficiently-trained staff, emergency procedures and equipment on the standby, and so on. For the architect of a 50-story building, it might mean a complete understanding of materials, wind dynamics, and engineering processes. For the software developer remediating a program’s Y2K problems, it means a scan for questionable variables, functions, settings, controls, and more.

Some of the items Y2K remediators must address lest their work be found to be negligent, and, therefore, subject to an award of money damages, include:

• Functions
• Function Arguments
• String variables.

Technical writings galore address these items in much more detail and also offer insight into Y2K problems inherent in particular programming languages. Read in your area of work for a greater understanding of these technical issues.

Lesson 2. The Battle of the Experts

How does Standard of Care arise in a lawsuit? It arises when the expert witnesses testify. Who can be an expert witness? Each state has its own rules of evidence about this, and they often track the Federal Rule. A portion of the Federal Rule is quoted here:

Rule 702. Testimony by Experts

If scientific, technical, or other specialized knowledge will assist the trier of fact to understand the evidence or to determine a fact in issue, a witness qualified as an expert by knowledge, skill, experience, training, or education, may testify thereto in the form of an opinion or otherwise.

Basically, just understand that an expert can be anyone who can convince the judge that he or she holds some expertise in the area of software Y2K remediation and that his or her knowledge will help the jury decide the case.

Let’s look at how experts testify. It goes something like this:

Q: Have you, Mr. Software Expert, had a chance to examine what Defendant Company did in this case during its attempts to fix the Y2K problem at American Electric Company?

A: I have.

Q: What have you looked at:

A: I have reviewed the contract between Defendant Company and American Electric Company, the programmers’ time records, the code changes made to the source code, the string variables scanned, the functions scanned, and much more.

Q: And as a result of your study, do you have an opinion as to whether the Y2K efforts of Defendant Company met the Standard of Care for companies involved in Y2K remediation efforts?

A: I do have such an opinion.

Q: Would you please state that opinion for the jury.

A: My opinion is that Defendant Company’s Y2K remediation efforts fell below the applicable Standard of Care.

Q: What do you base that opinion on.

A: I base that opinion on many things. For example…

Following the "For example," the expert takes your head off, reciting all of the ways your efforts were misdirected. This laundry list of what you did wrong will be limited only by the expert’s own creative genius.

How do experts decide what meets the Standard of Care and what doesn’t? This is the core issue facing developers. In other areas of professional practice–such as medicine–there’s an entire college of experts doing the same surgical procedures day after day. Likewise a long history exists of development of the techniques for the surgeries, tools used, and best practices. The same could be said for the legal profession, which also has been around for hundreds of years.

But what about software engineering? Here’s an infant profession with an evolving college of best methods and practices. In our industry, best practices established one day are tossed away the next. This happens because software changes relatively frequently. What’s true today is foolish tomorrow. How different from medicine, law, architecture, and accounting! And how vulnerable this makes us to the Y2K lawsuit threat, just because we don’t yet have a history of methodologies and best practices tested and true.

In a historical sense, you could say that we who are doing Y2K remediation–despite our articles and statements and press interviews–are largely working in a vacuum. And in a legal sense we’re working in a vacuum too; what we are doing hasn’t been tested in very many law courts. Whether our efforts turn out to rise above the bar or fall below remains to be seen.

Lesson 3. Lessons To Learn

First, when the lawsuit storm begins to swirl around us, we’ll need expert witnesses willing to tell the truth about the infancy of our profession. We need to demonstrate to juries how we were working with largely untested methodologies, and that we were working with issues never before faced in the history of software. And we’ll have to say about our efforts, "There was no one else to do what we did. We did our best." We won’t apologize for what we did; we’ll simply state the truth. How refreshing this could be.

Second, we need to work together to develop a Standard of Care for ourselves, rather than have it thrust on us from the outside. There are wolves out there, experts willing to say anything for the right price. As a profession we must develop a network among ourselves of experts who will tell the truth no matter how much money is involved, whether it hurts or helps. Truth must be our bottom line.

We owe it to ourselves, to our profession, and to those who will inherit our work to set a Standard of Care that begins with rigorous honesty. Only the professions that have done this have survived. The rest have dried up and blown away largely due to public efforts (read "Administrative Agencies") to police them. In our society if a group invested with a public duty fails to police itself for the public good, you can bet the government will step in. I believe government regulation of software development could be the worst thing possible for our infant profession, worse than any threat we face in dealing with Y2K issues.

Third, we must understand our position in society. As software professionals we have been vested with a public interest that is peculiarly unattainable by the citizenry, because source code isn’t something anybody could pick up, read through, and determine whether it meets Y2K compliance. We bear the same responsibilities to our clients as the physician, the attorney, the CPA. Clients rely on us to know the unknowable.

We must rise to a level of competence and thoughtfulness that not only tests our personal mettle but that brings out the best of our profession. We must establish once and for all that we’re more than geeks and propeller heads, that we’re facing and doing our best to remediate problems left in many cases to us by a generation of coders no longer around.

Once we do these things, we’ll have established our own Standard of Care.