Fun With Software Development Contracts

I generally try to keep my relationships with clients simple. Most of my day to day work is done through verbal discussions confirmed with a follow-up email. In my experience, if the relationship between myself and a client is good, a contract doesn’t help it, and if it’s bad, a contract won’t make it good. In this day and age anyone can sue anyone anytime for any reason, good or not; so a contract that spells “everything” out mostly provides a false sense of security for everyone.

In addition, if a customer cares about their reputation, they will pay a fair rate on reasonable terms. If they don’t care, they won’t keep their promises. It’s that simple. In my experience it doesn’t matter a whit what they agree to do up front; only execution matters. It’s the same from their perspective; they don’t care about my sales blather, they simply want me to deliver.

So, most paper contracts I have are short and sweet.

Once in awhile I deal with larger corporations, usually at arms length as a sub-contractor. But I made an exception today and signed a four-page opus, plus scope of work, for a firm large enough to have a corporate counsel. This guy has to justify his existence, so he initially produced the Contract from Hell.

Among its provisions:

• I’m obliged to deliver defect-free software and warranty it for six months after delivery; in other words, all bug fixes (or work perceived or claimed to be bug fixes) are done for free.
• I’m obliged to provide employment insurance even though I have no employees, and public liability insurance even though I will work 100% from home and customers never visit my home office.
• I’m to bill monthly, and I’ll be paid on net 60 terms, timed not from the invoice date, but from the date they get around to approving it. So in the best-case scenario I will carry an average of 75 days of accounts receivable on any given day of work I do. How utterly motivating!
• Although it’s a six month contract, for which I’ll turn down other work, and there is no way for me to unilaterally get out of it in advance, the customer can cancel on two day’s notice “for convenience”.

There’s more, but as you can guess, this work is extremely attractive to me or I would have indulged the deeply satisfying practice technically known as “telling the prospect to bugger off”. However, I managed with some effort (and the calming influence of my long-suffering wife) to produce a purely factual, non-satirical response calmly listing the seven or so things that would need to change if I were to sign the contract.

To my surprise, they caved on almost all of it, and gave me satisfactory explanations and assurances for what was left. I now have 30 day terms (from the date of an “undisputed” invoice), no requirements for needless insurance, no indulging fantasies of zero shared responsibility for quality assurance, and 30 day’s notice of any sudden whim to say “never mind”, rather than two days. It turned out that the person hiring me had never even looked at the contract, and admitted they wouldn’t have signed it themselves, if they were in my shoes. They metaphorically slapped the lawyer upside the head and said the “crap” had to go.

Fortunately I know the code base I’ll be working with intimately, because I wrote it five years ago myself, two mergers / acquisitions ago. I also know and trust a couple of the people involved with the project, and have visibility into what working with them is really like, because I know my predecessor on this gig well. But even so, this gig came close to not happening, or at the very least, to getting started on entirely the wrong foot.

I can almost hear some consumer of software development services out there bristling, “what’s so bad about a contract? It’s just the way things are done ™”. Well … maybe so, but a contract constitutes a policy rather than a guideline. To understand the difference, go here and consider Bob Lewis’ take on the matter. It’s excellent. Go ahead, I’ll be here when you get back.

Welcome back. Now you can see why any contract for work for hire should mostly consist of innocuous boilerplate that any honest contractor would sign without hesitation: we agree not to steal each other’s trade secrets or technology, or to use unlicensed technology in the work; we agree to pay a fair rate on reasonable terms; it’s understood that the work is to be done in a workmanlike fashion according to accepted industry standards; it’s work for hire and the customer owns the work product and the contractor lays no claims of ownership or intellectual property; the contract ends on such and such a day, yadda-yadda.

It’s when one side or the other attempts to shift all the risk to the other party, creating an adversarial relationship up-front, that things start out ugly and get worse from there. Or when the contract starts to spell out specific procedures about time sheets and reports and billing cycles and tools to be used and procedures to follow, and penalties and consequences of every conceivable breach — placing everyone in an anti-productive straight jacket.

The sad thing is, by all accounts this company is full of good and pleasant people to work with. It’s only the blasted lawyer that’s making them all look like … lawyers. It’s a problem that’s all too common.