Ask HN: Do you think its fair to charge for fixing bugs?
Putting myself in the client's position, why should I have to pay for some stupid mistake the developer made..? Not only do I have to pay for it, I also have to waste my time logging a ticket with a whole lot of detailed information. And THEN, I have to prioritize it over some other functionality that was already planned for the sprint..
5 comments
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...
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.
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"...
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"...
This is a good reference implementation.
https://news.ycombinator.com/item?id=7850335
In general, I would avoid selling software without a service agreement.
Bugs are a thing that happens. You will endeavor to make them happen less, because you're a competent professional. But because you're a competent professional, you know that some will happen anyway. So structure your business deals such that both you and your customer have a good answer to the problem. You shouldn't take a wash for being available, and they shouldn't be left hanging with nobody to get help from.
This gives you a tidy source of recurring revenue and an easy way to nudge up your average deal value. It gives your customers a reliable source for fixes and changes. It's good business all around.
https://news.ycombinator.com/item?id=7850335
In general, I would avoid selling software without a service agreement.
Bugs are a thing that happens. You will endeavor to make them happen less, because you're a competent professional. But because you're a competent professional, you know that some will happen anyway. So structure your business deals such that both you and your customer have a good answer to the problem. You shouldn't take a wash for being available, and they shouldn't be left hanging with nobody to get help from.
This gives you a tidy source of recurring revenue and an easy way to nudge up your average deal value. It gives your customers a reliable source for fixes and changes. It's good business all around.
If you are doing freelance work, you could roll maintenance development/fixes into an ongoing support contract which includes a SLA and monthly fees.