The future of Liability in Software
There are many things that set software companies apart from other businesses. A significant, but an often overlooked difference, is that the manufacturers of software exhibit little fear of getting sued for negligence, including defects or misuse of their software.
Even efforts to reform the Uniform Commercial Code (UCC) to address particularities of software licensing have literally been frozen in time for more than a decade. And as discussed in We Need Strict Laws, the courts consistently rule in favor of software corporations over consumers, due to the nature of contract law, tort law, and economic loss doctrine.
Slippery When Wet
If you go to your local hardware store, you’ll find warning signs on an empty bucket. Look around your house or office and you see warning labels on everything from wet-floors to microwaves and mattresses.
In software, if you are lucky you might find an EULA buried somewhere behind a link on some other page. Most products have a user manual, why is it not enough to print your “warning” inside? An easy to find, easy to implement standard.
Where is the fear?
Fear is socially moderated and generated. Hence the term “mass hysteria.” We fear things that we’ve already experienced or that have happened to personal connections. We all too easily imagine horrible events that have befallen others. In an age of multimedia, this is a rather flawed system that has gone berserk or as they say “viral.” What we see has left us with some pretty poor estimates on the odds of events, like shark attacks or kidnappings.
One reason we don’t fear lawsuits around software is that we don’t see them in the public sphere. They do happen, but all too often the cases never make it very far. Or the judge rules in favor of the software developer. Interpretation of the laws makes it difficult to prove or attribute harm to a customer.
To date, we’ve yet to see a Twittergate on negligence in software development. This doesn’t mean that no one has reasons to sue, but rather that cases can’t be won. For the moment, the law and the precedent aren’t written to guide software litigation. And with little news or discussion in the public sphere, no one has the “fear.”
A Matter of Time
Frankly, it is not a matter of will it happen, but when? What is the likelihood that in the next 5 years there will be successful suits brought against software firms? Should we make a bet?
Software development is an odd industry. We leave an incredible electronic trail of searchable data for everything that we do. We track defects, check-ins, test reports, audit trails, and logs. And then we backup all of them. Quite often these records last forever. Or at least as long, if not longer than the company that created the record.
Even when we change from one source control system to another we try to make sure that we keep a detailed record intact just in case we want to go back in time.
This level of record keeping is amazing. The safety it provides and the associated forensic capabilities can be incredibly useful. So what is the catch? There is a potential for this unofficial policy of infinite data retention to backfire.
Setting the Standard
Most companies follow standard document retention policies that ensure businesses save both communications and artifacts to meet fiscal or regulatory requirements for a required period of time then eventually purged after a number of years.
Ironically, even in companies who follow careful document retention policies, the source control and bug tracking system is often completely overlooked if not flat out ignored. From a development perspective, this makes sense: data storage isn’t expensive, so why not keep it all?
The Catch & The Cause
The reason that document retention policies exist is not simply to keep companies organized and the IRS happy, it’s because of the potential for expensive lawsuits. Companies want to make sure that they can answer categorically why certain documents do or do not exist.
For instance, let’s say your company makes widgets and tests these before shipping them on; you don’t want to say that “we don’t know why we don’t have those test results.” By creating a documented process around the destruction of data (and following it) you can instead point to the document and say the data does not exist — it’s been destroyed according to “the policy.”
Policy? What Policy?
This takes us back to the story of liability in software. In the software business we often keep data forever, but then we also delete data in inconsistent bursts. Maybe we need to change servers or we are running out of space or we find random backups floating around on tapes in vaults. So we delete it or shred it or decide to move to the Cloud to reduce the cost of storage.
This type of data doesn’t really tend to carry any specific policy or instructions for what should and shouldn’t be included, how the data should be stored, and so on.
What’s more, when we document our code and record check-ins, we don’t really think about our audience. Or default audience is likely ourselves or the person(s) in the cube next to us. And our communication skills on a Friday night after a 60-hour-week won’t result in the finest or most coherent checking comments, especially if our audience ends up being someone besides our cubemate.
The reason that this type of mediocre record keeping persists is that it remains difficult to sue over software. There really are no clear cut ways to bring a suit for defective services provided. If you live in the US you know the fear of lawsuits over slips and falls; this fear does not exist for creating a website and accepting user data.
Walking a Thin Line
My guess is that this indifference to record keeping and data retention will persist as long as potential suitors must do all the groundwork before seeing any money. And, as long as judges continue to side with corporations and leave plaintiffs in the lurch. However, as soon as that first case sneaks through the legal system and sets a precedent, anyone and everyone just may reference that case.
Ironically, patents or copyright protection don’t travel with theories presented in a trial, which means that once a case makes it through the system the case only needs to be referenced. Meaning that if one lawyer learns how to sue us; they all do. Think of it as an open source library you can reference, once it exists anyone gets to use it.
My expectation is that there will be a gold rush, we are just waiting for the first prospector to come to town with a baggy of nuggets.
As to what companies can do? For now, create an inventory of what data you keep and how it compares to any existing policies. This may involve sitting down in a meeting that will be an awkward mix of suits and shorts where there likely will be a slide titled “What is source control?” There is no right answer, and this is something for every company to decide for themselves.
Where does your development process leave a data trail? Has your company had discussions about document retention and source control?