Cult of the NDA 2014

The dot-com boom is in full force again, and with it the Cult of the NDA.  Seems that every time you bump into someone, they want you to sign their confidentiality agreement before they split a bar tab.  If you are a software consultant or contractor, you will have to sign many NDAs between now and the next crash of the NASDAQ, so here's a handy little guide for what to look for -- and what to look out for -- before signing.

 

Must Have

If these things are not in the NDA, you should walk away from the contract.  Without these provisions you've voluntarily accepted a time bomb which could destroy your company.

A Clear Definition of what constitutes confidential materials.  This definition will often be quite broad, but should prevent someone from retroactively redefining something as confidential after disclosure.

Exemptions for three things: stuff you already knew before signing, stuff made public without your involvement, and stuff you are required by law to disclose to a court or law officer.  NDA-writers often forget the last, but in these Patriot Act days, you can't afford to.

A Time Limit.  These will often be quite long, like five or seven years, but you don't want to sign an NDA you'll pass on to your grandchildren.

Would Like

There are a couple things which you'd like to get into an NDA if you can, but aren't essential.

You'd like the NDA to be Mutual; that is, it should protect your secrets as well as the client's.

If you're going to be doing open source work, the NDA should contain an Exemption for Open Source Code release.  Often you can put this in the Statement of Work if it's missing in the NDA, though.

A defined Procedure for Granting Exceptions from the NDA.

Can Tolerate

There's a bunch of stuff which often appears in NDAs, and you're not really keen on, but it's standard and you shouldn't balk over it.

Right to a Preliminary Injunction for the client.  This is normal; it just means that they can slap you with a gag order if they thing you're disclosing secrets, until it goes to court.

Jurisdiction in the Client's Home State: just like you want the jurisdiction to be local to you, the client wants the same.

A "Reasonable Care" requirement for handling confidential data.  This is, after all, only reasonable.  Although at some point you should talk to your lawyer about what this specifically means in your state.

A Remediation Procedure if data is disclosed: this is normal for contracts tied to vendors under HIPAA, SOX, or PCI.

Warning Signs

Any of the below appearing in an NDA is a reason to send it to your attorney for specific review.  Several of them appearing together is a reason to run, not walk, away from the negotiating table.

• Indemnification for third-party suits resulting from a violation of the NDA.  This requires you to have D&O insurance, among other things.
• Weird Legal Jurisdictions, such as another country, or a state which isn't yours or theirs.
• Right to Examine Your Files: they can't do this without violating your confidentiality agreements with other clients.
• "Utmost Care" or other weakly defined standards of secrecy.
• A "No Reverse Engineering" clause without an "unless required for performance of Services" clause. 
• Limitations on Work for other companies, "competitors", or "companies in the same industry".  If you sign these, eventually you won't be able to work at all.
• Excessive Length is a warning sign on its own; if the NDA is more than 2 pages and doesn't contain a full HIPAA or PCI agreement, then it's probably hiding something.

Hopefully that helps fight the cult.  Happy contracting!

NOTE: Josh Berkus is not an attorney, and the above does not constitute legal advice.  You should always consult your own attorney on specific contracts and agreements.  Further, the above advice is heavily slanted towards California law (but then, so are dot-com NDAs).

20 Rules of Software Consulting

I'm going to be gradually republishing some of my older content from my prior blogs here so that people can find it again.  I'll also be updating the stuff which needs updating, of course.   Here's a revised and updated favorite: the "rules of software consulting".

1. Technology Reflects the Business: show me a client with a chronic software problem, and I'll show you a client with a chronic management problem.
2. Three Things You Will Never See:
   a. A timeline which is too generous;
   b. A client who pays too quickly;
   c. An accurate and complete specification.
3. Half of Applications Are Immortal: "temporary, one-off" applications often last for years, and there is code from the 1960's which is still running today. Always plan for longevity.
4. Bad Clients Will Destroy Your Business: half of your success will be built on the ability of recognizing bad clients and avoiding them or terminating their contracts before they suck away all of your time and resources. Always be able to walk away, even if it means giving a refund.
5. Ask Not What's Possible: the question is not what you can do, the question is how much the client is willing to pay for it and how long they will wait.
6. Time Substitutes for Money on a Logarithmic Scale: e.g cutting the time by 20% will require doubling the budget. Cutting the budget by 30% will quadruple the amount of time.
7. All Estimates are Optimistic: new application development will take three times as long as you expect, and cost twice as much. Or vice-versa.
8. Three Things You Will Never Have Enough Time For:
   a) The specification and prototypes
   b) Documentation
   c) Code maintainability
9. All Substantial Applications Have Platypuses, which are objects or bits of data which defy all attempts to fit them to well-defined business processes. Platypuses are both why perfect data integrity is unachievable, and the source of at least 30% of troubleshooting.
10. Don't Call it Refactoring:  clients never pay for cleanup, even if that's what they need.  Figure out a way to call the refactoring something else so you can get it done.
11. The Longer You Wait to Refactor, the Longer It Will Take. Major template or schema changes at production time are particularly deadly.
12. Always Have a Contract, even for one-day jobs. Also, use your own contract, and not the client's, and have your contract written by a real attorney. It's worth it.
13. The Contract-Writing Process Is a Litmus Test for Its Fulfillment. If the client spends a lot of time arguing over the contract, then actually working with them (or getting paid) will be even more difficult. If the client insists on an odd and obscure clause, they're planning to exercise it.
14. The Client Has Very Poor Memory: no matter what they sign, the client will have forgotten what they agreed to within days, if not hours. Document all requests and changes and keep copies.
15. Never Agree to a Fixed Bid for anything where you have not done the same exact task at least twice before.
16. Third Parties are Incompetent: never agree to a fixed bid or success-based payment for any task which is even partially dependent on the speed, documentation or product quality of a third party not under your direct control. This means no fixed bids for data interchange or fixing other people's code, ever.
17. The Client has No Taste: never allow the client to choose your tools, your subcontractors or your work environment. Or at least charge them a lot extra for the privilege.
18. Always Bill for Meetings, or you will spend half your life attending them.
19. A Half-Empty Mailbox Is The Exception: usually, if one client decides to pay unusually late in a month, all of your clients will. Always be able to survive 60 days on your savings.
20. A Sufficiently Late Project Will Never Be Completed.  In general, any project which is more than 150% past its original deadline has sufficient systemic issues to permanently prevent delivery.