Saturday, March 12, 2016

The evolution of a contract

Just about a year ago, I contacted a lawyer about overhauling the contract I've been using with clients.  What I was then using was essentially split into two parts:
  1. The "legalese" that defined terms, spelled out the conditions under which a Party could "fire" the other, etc.  Basically what contracts are expected to do.  Much of it has been borrowed from contracts I've signed in the past, and translated (as far as possible) into The Queen's English.
  2. The "Statement of Work," which was specific to the client project at hand.  It described the work to be done, and then itemised it with the amount of fee allocated to each line-item of the overall deliverable.
The first and main criticism the lawyer brought was that the two documents should be streamlined into one atomic unit.  Fair enough, I suppose.  Problem was, the new version was likewise partitioned into a "legalese" part and a "technical" part.  Without, I might add, any attempt to ameliorate the legalese for the benefit of anyone whose writing skills haven't been demolished by Law School.  No attempt, that is, besides wholesale cutting and pasting of my original verbiage into what looked for all the world like the bolted-together results of a LexisNexis search.

In short, it was a Frankencontract, large swathes of which didn't even apply to what I, you know, actually do for my crust.  Grrrrrrrrrrr.

I made one wholesale revision myself, then made my dissatisfactions known when we reviewed the mark-ups over the phone.  The second draft wasn't as dreadful (or nearly as long).  But halfway through amending its sins, I gave up on a hopeless cause.  No point in paying someone to do their job for them.  Surprisingly  (or perhaps not) I never heard from the lawyer again. 

This week, I pulled out the standard contract I've been using since last year's debacle, and realised, "Aw, Grethor--I can't believe that we never even thought to mention Secure Sockets Layer (SSL)..."  So into the mix that went, and the end of the contract inched (or centimetered, for metric contracts) down on the page.  Sigh.

To re-purpose an old adage, good contracts come from experience, which come from bad contracts.  Or, much worse, no contract at all.  For a freelancer or small business, paying a lawyer for a standard contract makes it tempting to treat it like Holy Writ.  Or The Necronomicon, depending on your view of the legal profession.

But, to me, a contract is more like DNA.  As it should be.  Because a contract is a living document that can, and should, evolve with its business.

Now, I prefer to think that successful business-to-client or business-to-business relationships are the default.  (Because the vast majority of us mean well...riiiiiiiight???)  Failure, then, is what designers and programmers call "an edge-case."  And, while there typically are multiple paths to success (even with detours and construction), the paths to failure are legion.   (Pretty much the opposite of Stairway to Heaven vs. Highway to Hell, when you think about it...)  And so contracts mostly exist to head off edge-cases (or at least to define what happens when a business relationship goes off the proverbial rails).

What's interesting to me, however, is when a business has survived enough mutations of its revenue model to acquire what in biology is known as "junk DNA."  (It's also known as "Non-coding DNA," but the programmer in me takes no small exception to that, y'understand...)  At one point, up to eighty percent of human DNA had no "explainable" purpose.  Later science has emphatically questioned that.  (Not surprisingly, I might add.  Not only does Nature abhor a vacuum, she is also an incorrigible pack-rat.  Honeybees being a case in point.  But don't get me started on that.  No, really.  You don't have that kind of time...) But a certain percentage of it nevertheless is purely vestigial.  (And thus the analogy holds.)

And, of course, the role of parasites in evolution is not to be underestimated.  For good and ill, by the bye.  As it turns out, the absence of nemeses for our immune systems may actually correlate to other problems.  (Because, after all, what's a comic-book superhero/ine without a monologuing super-villain, I ask you?)  Alas, it takes all of one bad actor to trigger a Cambrian Explosion of clauses in the contract of the party acting in good faith.

Yes, I realise that the "Lawyers are why we can't have nice things" meme has been fashionable since at least 1591.  But I would encourage my fellow software developers (particularly the freelancers) to re-think their opinion of contracts.  I've already mentioned edge-cases, which is certainly something that any dev. can wrap their think-meat around. 

But, far more importantly, the entire process of negotiating and signing a contract is an invaluable preview of how the project will likely run.   Just a handful of possible scenarios:
  • Client signs your contract without question:  Woo-hoo!  You and your lawyer did a bang-up job with that contract, yes?  Nope.  This signals zero attention to detail on the part of your client.  And it's going to bite you in the butt--possibly both cheeks.  Unless you have a P12+ Telepath on your team, you're screwed.  Get written sign-off on every deliverable, grow a thick skin, and have your lawyer's burner phone on speed-dial.
  • Client sends you a contract that they obviously didn't (or didn't want to) read:  Pretty much the same problem as above.  This tends to happen with larger, institutional clients.  Tip-offs included (but are not limited to) references to obsolete technologies.  Tactically, consider it a cry for help and negotiate.  (And, for pity's sake, work your otherwise billable time and that of your lawyer's into the project cost.  You are emphatically not in business to compensate for their flabby Legal Dept.!)  Strategically, consider it an orange flag; bill them incrementally--that place has clearly been infested by bean-counters, martinets, and gold-brickers.  Collect your fee ASAP and don't hand over the IP until the cheque clears.
  • Client won't discuss the project with you before you sign an NDA:  Not necessarily a red flag; it depends on how bleeding-edge the idea turns out to be.  You've been around long enough (or at least hang around with people smart enough) to know that ideas mean bupkis without execution.  Unless your spider-senses--by which I mean your personal network--tell you that these folks are working on something very close to your pet projects (or the projects of your existing/potential clients), you're probably safe.  However, you will not be able to use them as a references for rain-making.  Factor that into your pricing accordingly.
  • Client pushes back on item/project cost:  Groovy.  They're doing their job.  If they're funded by VC or public money, this goes double.  (If they're funded by VC or public money and they don't push back, write them off for future business...and referrals.  Also, make a note of their names for when they invariably attach themselves to another startup.)  You are ready for this, because you've already crunched the cost-benefit numbers.  (Riiiight???)  One caveat:  If you've already been through a few projects with the client and the push-back isn't a formality, you have a trust issue that needed to be resolved a long time ago.
  • Client pushes back on Intellectual Property (IP) ownership:  Also not a bad sign.  Again, you've crunched the numbers enough to know what you're giving up, and you know what they're willing to pay for that.  So it should be an easy call.  Also, you know better than to hand over the work until the cheque has cleared.  So you're not going to budge on that point.
  • Client insists on a handshake agreement:  Nope.  Seriously.  Just nope.  Get the heck out of there.  Now.  There are other clients waiting for your help. 
In short, put on your "Sherlock" hat and make a game of it, if that's what it takes to keep your analytical skills engaged on the business side of freelancing.  Because your business exists to survive, not to provide an interesting fossil.