What are contracts useful for?

During this year’s I.T.A.K.E. Unconference, Alexandra Marin started an open space about freelancing and running your own business. I’ve been doing consulting and contracting for years, and I keep seeing the same misconceptions on developers who are just starting, so I jumped in to see if I could contribute.

Contractual misconceptions

Here’s what I’ve found, over the years, is the main misconception held by developers who are just starting to look for clients: what contracts are useful for.

Ask that of a newly minted contractor and they’ll immediately reply “to protect me!”.

Then you say that no, that’s not what they’re useful for. They’ll hesitate, then tentatively (and with significantly less enthusiasm) reply “um… to protect the client?”.

Say that no, again, and they will be thoroughly confused.

Here’s the reasons why contracts aren’t particularly good at protecting anyone:

• If there’s ever a strong enough disagreement that you need to argue over contractual points, both parties have lost already;
• If after such a disagreement things end up in a fight, whomever has the more money to pursue an issue, wins by exhaustion;
• And if that wasn’t enough, in today’s global environment, chances are both parties aren’t even in the same jurisdiction anyway, making a contractual dispute in court unlikely.

What are they good for, then?

This what contracts are really useful for: setting expectations up-front. They tell everyone involved what they should expect from the process.

Part of this comes from how every part behaves during contract negotiation, but that could be a post in and of itself, so let’s keeps our eyes on the piece of paper you’re signing.

At its most basic level, a contract says who should do what, and when. It delineates future behavior. There should be no assumptions, nothing implied, and not a single point that if someone asks you about, the answer is “well, that’s just understood”. If something is “just understood” and not explicitly stated, both parties may end up coming away from a contractual agreement with different expectations.

There’s a reason why this distinction of a contract “protecting you” versus “clarifying expectations” is fundamental, and goes even more so for software engineers.

I’ve seen too many developers treat a contract as a test suite. Since they think a contract is meant to protect them, they expect that as long as all tests are green, nobody will complain.

That mentality misses a fundamental point. As a developer, your job is not to produce code: your job is to keep the client happy. Producing code is only a fraction of that. Keeping the client happy is not only following the contract, but also requires expectation management, client handling, regular contact and a whole bunch of other tasks that developers hate to do. Yes, you may find them to be a pain, but they are a lot more important than relying on the letter of the agreement to cover your behind.

Otherwise, you fall into a mentality where you believe that as long as your behavior is passing all contractual test cases, then it’s all A-OK and the rest is not relevant. That’s a mistake.

It’s all about the expectations

A contract will help you define expectations, so you should phrase and review it carefully. But you just shouldn’t think that abiding by it will be the sole measure of a successful engagement.

And if you must see it as a behavior test suite, think of it this way: nobody cares if your work passes all tests, if it crashes and burns when it encounters actual users. Even if you think of it of the agreement as a test suite, make sure you don’t lose sight of the importance of your own user-friendliness.

A contract will help you if you ever need to demonstrate you have lived up to your end of the bargain, but hopefully, you’ll never need it to. Where it will consistently help you is in making sure everyone’s expectations are clear from the start.

Don’t overlook that.

Thanks to Dmitri Sotnikov for reviewing the first draft.

Published: 2016-05-30