When you don't get paid until your product meets predetermined test criteria, that fact will keep you from falling into the various traps that plague large system design. First of all, you can't enter into such a "deal" when the customer/client simply says, "I just want it to work" rather than providing or at least agreeing upon acceptance test criteria.

In either case, however, documented requirements and documented test spec's will prevent a lot of headaches. When you can go to your customer and say, "Here's the deliverable, here's the result of testing, now pay me." You're done. If you have less than firmly documented design and test criteria, you're never done.

Naturally, it's hard to get clients/customers to sign off on performance and test criteria, because it limits their ability to change the job in mid-stream. My response to such changes is generally, "Yes, we can do that, but bring money, as we have to terminate and renegotiate our arrangement." That first requires that we be paid for what's been done, irrespective of whether it benefits the client/customer who has changed his mind about what he wants.

If you want to produce a reliable product, you have to have etched-in-stone requirements against which you can produce etched-in-stone acceptance test criteria and procedures that verify that you've met them. Clearly, you have to have etched-in-stone requirements, else you will be unable to prove you've met the terms of your contract.

In the end, you have to get paid, regardless of how elegant or otherwise your work product happens to be. Design-for-test is the sure way to get your money.

RE