Josh's Rules (of Database Contracting)

These are advices from a PostgreSQL lead.
------------------------

I spent eight years as a full-time database applications consultant. Since I'm out of that racket for the time being, I thought that I should write down the little lessons I learned the hard way before I forget them all. Feel free to add your own in the comments.

Data Reflects the Business: show me a client with a chronic database problem, and I'll show you a client with a chronic management problem.

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.

Database Applications Are Immortal: the average lifespan of a "temporary, one-off" application is 4 years, and there is code from the 1960's which is still running today. Always plan for longevity.

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.

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.

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.

All Estimates are Optimistic: new application development will take three times as long as you expect, and cost twice as much. Or vice-versa.

Three Things You Will Never Do:
a) Spend too much time on the specification and prototypes
b) Write too much documentation
c) Be too concerned with code maintainability

All Substantial Database Applications Have Platypuses, which are 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 40% of troubleshooting.

Data Integrity Is Its Own Reward: each 1% data integrity failures will double the amount of time you spend troubleshooting them.

The Data Integrity Tipping Point: any database which contains 20% or more untrustworthy data is useless and will cost less to replace from source data than to fix. For some applications, the level of complete failure is lower.

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.

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. If you can't afford to walk away from the table, you can't afford to negotiate.

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.

Never Agree to a Fixed Bid for anything where you have not done the same exact task at least twice before.

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.

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.

Always Bill for Meetings, or you will spend half your life attending them.
The Longer You Wait to Refactor, the Longer It Will Take. Schema changes at production time are particularly deadly.

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.