Apr 132014

Over the years, I’ve had the opportunity to read a few contracts.  Some of them I was expected to agree to and sign, others I just happened to read to see what commitments we had made to customers.

Now there are certainly some contracts that I don’t bother reading because it probably isn’t worth my time.  These are things like iTunes agreements which are 70 pages long, and most software licensing agreements.  But some are more exciting, like customer service contracts and employee agreements.

And it’s amazing what gets put into these things.  Really amazing.  And clearly nobody reads them, or if they do, they misread them.  here are examples of some of the stuff I’ve come across (paraphrased):

  1. Any wrong-doing by the Corporation is cause for dismissal of the Employee.
  2. We warrant that the product does not meet our published specifications.
  3. None of the above shall restrict the Employee from purchasing the generally available shares in any public company, provided said public company competes with the Company and provided Employee and Employee’s family do not control, in aggregate, more than 3% of the shares of said public company.

In each of these, the logic is backwards to what one expects.  In fact when many people read them, they also immediately read what the clause was supposed to mean, not what’s actually written down.  This doesn’t mean that you’d want to agree to it.  Of course, if you’re desperate for a job, you might not want to rock the boat too much.

But how does this stuff happen?  I can imagine in some cases that a contract has been around for a few years, and every once in a while, somebody edits the current corporate contract.  In some cases the person doing the editing doesn’t understand why a clause was in place and when they notice something that looks like it may be bad for the company, they turn the logic around.  Either that, or somebody is adding a sub clause to add some new restriction, or to specifically remove some implied restriction but they just get the logic wrong (1, 2, 3).

This sounds exactly like software development.  Without adequate controls on software, programmers will fix features and add bugs all the time.  At one company, we specifically implemented a process that required the programmer to write a proposal for fixing a bug or adding a feature, and this would be reviewed by a senior developer.  This was in response to programmers removing features (usually security or privacy related) because somebody reported them as bugs!  The success of this depended, of course, on the senior developer knowing what the software was supposed to do.

Some of the latest techniques for avoiding this are things like design by contract and test driven development.  These effectively give you a reference against which to check the code.  The idea would be that hopefully you didn’t get the logic wrong twice, so once you’ve got software that passes your tests or satisfies your contract you’ve got a good place to start from for next time you want to make changes.  The tests, in particular, should still pass even if you make changes to the code to add new features.  If they don’t, then you need to go fix what you just broke.

I wonder whether companies should always have a lay-speak version of their contracts maintained with the contracts that describes the intent of each clause and sub clause.  This way someone can read two versions of the same clause and if they clearly don’t agree, then something needs to be fixed.  Somewhere the intent needs to be documented so that random edits don’t expose the employee to lawsuits for patent infringement!  One could also imagine that this second document could include test cases like: ” Employee’s wife owns controlling shares in a Filberts Dairy Farms, a public company with shares traded on the TSE.  This ownership MUST be permitted by the agreement.”  (clause (3) would fail this test if the Company was an Oil company, because the Farms do not compete with the oil company!).  But can this be automated?

 Posted by at 12:29 pm