Sure, the client is always paying for it anyways...
If he doesn't wanna pay for defect correction, you are just going to spend a lot more time on that before you deliver (i.e. your estimates goes up)....
Finding subtle bugs is increasingly difficult as the code quality goes up, so each bug is getting increasingly costlier to find before it hits the real world.
Even well-tested code will not be defect free unless an incredible amount of effort is spent. (We are talking orders of magnitude more than regular clients are willing to pay for). Look for the NASA study on code quality and look at their productivity to achieve that (granted, brilliant) code quality.
Personally (as an freelancer), I comp the really, really stupid oversights (and their diagnosing time)... That shit happens once in a while (and that comping buys you a lot of credibility)... but the "normal" (i.e. somewhat trickly) bugs, they client pays for them.
For new customers, I usually have a "facts of software development" talk, so that they know how and why I do stuff... (most customers appreciate the frankness and have no problem paying for bugfixes afterwards - if they do, I simply add margin to their estimate that gives me room for expected later bugfixes).
If they balk, when you say that you cannot write defect free code... ask them if they ever find typos in documents or wrong calculations in spreadsheets even after they spend "a lot" of time to make sure they were correct...
I usually use the "car warranty" analogy. That "free" 3 year service plan is not free. It's just built into the price. We're just more transparent, that's all. I like you're "typo" example as well.
The "facts of software development" is really important, especially if the client hasn't got a lot of experience in developing products. I've always found the more experienced a client is, the easier they understand the concept.
Yeah, I try to only take clients that have been in the game for a few years - or really go heavy on the "facts" speak...
Most clients are reasonable, but the newb ones simply don't know the realities and mechanics.
And it's when you have a different view on reality, that you get unhappy with each other...
I also tell my "newb" clients, that the first project is perhaps 50% of the total, even if it delivered on time and on spec (for bigger projects)... But the spec is always incomplete and wrong, so fixup is going to be needed, because we learn while we do the first version and the first "real deployment"...
If he doesn't wanna pay for defect correction, you are just going to spend a lot more time on that before you deliver (i.e. your estimates goes up)....
Finding subtle bugs is increasingly difficult as the code quality goes up, so each bug is getting increasingly costlier to find before it hits the real world.
Even well-tested code will not be defect free unless an incredible amount of effort is spent. (We are talking orders of magnitude more than regular clients are willing to pay for). Look for the NASA study on code quality and look at their productivity to achieve that (granted, brilliant) code quality.
Personally (as an freelancer), I comp the really, really stupid oversights (and their diagnosing time)... That shit happens once in a while (and that comping buys you a lot of credibility)... but the "normal" (i.e. somewhat trickly) bugs, they client pays for them.
For new customers, I usually have a "facts of software development" talk, so that they know how and why I do stuff... (most customers appreciate the frankness and have no problem paying for bugfixes afterwards - if they do, I simply add margin to their estimate that gives me room for expected later bugfixes).
If they balk, when you say that you cannot write defect free code... ask them if they ever find typos in documents or wrong calculations in spreadsheets even after they spend "a lot" of time to make sure they were correct...