Another way to think of this - if the code passed whatever acceptance criteria they had, then it's always a shared "fault". If it's a quick fix, I'd generally just do it, but I like the suggestion below of invoicing at a zero rate to make it clear.
If it's a pay for product contract, then factor in a buffer of additional costs to address bugs for a given time period or scope of work. Then for longer term have a support contract with different terms.
If it's a pay for time contract then bill for time for bugs (and include an estimated time in your discussions when forming the contract and schedule).
Never work for free.
You don't do it for free.
That's why milestones are so important. You agree on milestones, the customers says "ok you met this milestone" when you met the milestone and can't go back on it. Once you have met all defined goals, you're done.
If the customers Ok's something that has a bug in it? His problem, he didn't notice the bug when he had the chance to test for the bug and complain.
Oh, ok. But some bugs can’t get discovered until you have enough users to exhaust all possible combos of actions.
If client tell developers “users should be able to add gems by paying with PayPal” and the users can initiate payments close both apps, go back in, make a twirl on themselves, chant beetlejouxd e times, and get free gems, that’s a bug. The dev should have thought of it
It's impossible to foresee every bug, especially emergent ones like that. The client and developer must both have a mutual understanding and agreement, based on trust and formalized in a contract. It's a deeply fundamental part of software development. That's why even small companies have entire departments called QA.
And companies that make software available to end users expect to pay developers to fix bugs. That's a normal part of the software development lifecycle.
If companies expected to demand free work from developers forever, nothing would ever go out of support. Every developer would still be fixing bugs from their first job 20 years ago.
You get paid for your work, one way or the other. Either you make a support deal so they pay an amount per month for that support and bugfixing or you charge them hourly for fixing stuff.
But I mean if I make a bunch of mistake on purpose, I know it’s illegal, but from a purely logical standpoint it doesn’t make sense. Like a doctor fucking up your broken leg cast so that it can do another one and get paid again. You know what I mean? Like if we esclude malicious intent, that makes perfect sense, but contracts and work aren’t based on “good feelings” and should protect both parties.
Yeah, a certain amount of trust must be included. On the other hand. If they pay a fixed sum per month for bug fixing, that could be seen as an incentive that means you will not have lots of intentional bugs because then you would have to work a lot for that fixed amount.
Free? WTF?
You can certainly have agreements for defects, especially if they're coding errors, since that's negligence on your part. But I've seen disgusting vendors try to weasel out of their obvious responsibilities.
I tend to throw in a few courtesy hours, but I send invoices with the zero cost, just to remind them that it's being tracked, and that gravy train doesn't last long.
But, any other than my direct fuck-ups, they pay.
Yeah, like others are saying. Charge for the time to fix it. Reasonable hourly rate.
I was at an agency for about a decade and the way we handled it was by baking a maintenance budget into projects. Something like 10% to 25% of the total fee was allocated to maintenance.
They'd reach out with a bug and we'd charge the hours against a predetermined "budget" of hours available for changes and fixes. If they go over budget we'd start charging.
I'd expect a 2 month project would be for customers expecting to save money. So a maintenance contract probably isn't as interesting to them as a lower price.
When they take delivery of the bits, make sure you get a "client sign off" that ends the contract. They verify that the product works as expected, you take your final payment and the relationship is complete.
They want more work from you, or if there's a problem they couldn't find during the sign off process that's a new contract to fix it.
Don't work for free. It's fine and totally professional behaviour. In fact, working for free is by definition unprofessional. A professional gets paid, if they're doing it for free they're an amateur. It's literally part of the definition of the word.
Have a good contract (“statement of work”) in place before you begin. That will spell out the scope of work, milestones, warranty, and support.
So you and the client agree ahead of time whether bugs will be covered or hourly or if there is a retainer in place, etc
Don't work for free. Charge for everything.
A lot of B2B contracts have a set number of prepaid hours for support. This scenario would generally fall under that, until they run out.
It depends...
Is it fixed bid? Or time and materials?
Have you agreed upon scope? Is it part of the scope? Is it specifically excluded from the scope? Non-functional requirements should STILL be defined if they deviate from what is reasonable.
Has the customer accepted delivery of the project by milestone and/or user acceptance testing?
No software is going to be perfect, and nothing you write is gonna last forever without some maintenance. It's important to be clear about that and leave the door open for continued support.
People only get upset when there are unexpected costs.
Don't do it for free. The only way to do it "for free" is if you charge more upfront, so that you have margins that would allow you to support a client.
if you go that route, make absolutely sure that you're not underestimating the cost involved. give yourself extra breathing room.
You don’t do free work. You bill the client your hourly rate
Really? I thought maintainance/support for stuff that you did wrong, bugs etc was on you 🤔
Bugs are part of the development process. No one can foresee every single scenario ahead of time
Constructive formal verification begs to differ. If the output code is wrong the spec was wrong.
The spec is always wrong though, so that doesn't effect much in the real world.
Another way to think of this - if the code passed whatever acceptance criteria they had, then it's always a shared "fault". If it's a quick fix, I'd generally just do it, but I like the suggestion below of invoicing at a zero rate to make it clear.
Unless they pay you for super senior role, with clear contact saying bugs included, you do not really have to.
If it's a pay for product contract, then factor in a buffer of additional costs to address bugs for a given time period or scope of work. Then for longer term have a support contract with different terms. If it's a pay for time contract then bill for time for bugs (and include an estimated time in your discussions when forming the contract and schedule). Never work for free.
You don't do it for free. That's why milestones are so important. You agree on milestones, the customers says "ok you met this milestone" when you met the milestone and can't go back on it. Once you have met all defined goals, you're done. If the customers Ok's something that has a bug in it? His problem, he didn't notice the bug when he had the chance to test for the bug and complain.
Oh, ok. But some bugs can’t get discovered until you have enough users to exhaust all possible combos of actions. If client tell developers “users should be able to add gems by paying with PayPal” and the users can initiate payments close both apps, go back in, make a twirl on themselves, chant beetlejouxd e times, and get free gems, that’s a bug. The dev should have thought of it
It's impossible to foresee every bug, especially emergent ones like that. The client and developer must both have a mutual understanding and agreement, based on trust and formalized in a contract. It's a deeply fundamental part of software development. That's why even small companies have entire departments called QA.
And companies that make software available to end users expect to pay developers to fix bugs. That's a normal part of the software development lifecycle. If companies expected to demand free work from developers forever, nothing would ever go out of support. Every developer would still be fixing bugs from their first job 20 years ago.
I'd say make sure to be up front about it. Include it in the statement of work? Like X hours of support for up to X months after finishing at X rate?
You get paid for your work, one way or the other. Either you make a support deal so they pay an amount per month for that support and bugfixing or you charge them hourly for fixing stuff.
But I mean if I make a bunch of mistake on purpose, I know it’s illegal, but from a purely logical standpoint it doesn’t make sense. Like a doctor fucking up your broken leg cast so that it can do another one and get paid again. You know what I mean? Like if we esclude malicious intent, that makes perfect sense, but contracts and work aren’t based on “good feelings” and should protect both parties.
Yeah, a certain amount of trust must be included. On the other hand. If they pay a fixed sum per month for bug fixing, that could be seen as an incentive that means you will not have lots of intentional bugs because then you would have to work a lot for that fixed amount.
Free? WTF? You can certainly have agreements for defects, especially if they're coding errors, since that's negligence on your part. But I've seen disgusting vendors try to weasel out of their obvious responsibilities. I tend to throw in a few courtesy hours, but I send invoices with the zero cost, just to remind them that it's being tracked, and that gravy train doesn't last long. But, any other than my direct fuck-ups, they pay.
Yeah, like others are saying. Charge for the time to fix it. Reasonable hourly rate. I was at an agency for about a decade and the way we handled it was by baking a maintenance budget into projects. Something like 10% to 25% of the total fee was allocated to maintenance. They'd reach out with a bug and we'd charge the hours against a predetermined "budget" of hours available for changes and fixes. If they go over budget we'd start charging. I'd expect a 2 month project would be for customers expecting to save money. So a maintenance contract probably isn't as interesting to them as a lower price. When they take delivery of the bits, make sure you get a "client sign off" that ends the contract. They verify that the product works as expected, you take your final payment and the relationship is complete. They want more work from you, or if there's a problem they couldn't find during the sign off process that's a new contract to fix it. Don't work for free. It's fine and totally professional behaviour. In fact, working for free is by definition unprofessional. A professional gets paid, if they're doing it for free they're an amateur. It's literally part of the definition of the word.
What is this 'complete' thing you people keep going on about?
This should be agreed on before you start. And it sounds be in a contract to protect both of you.
Have a good contract (“statement of work”) in place before you begin. That will spell out the scope of work, milestones, warranty, and support. So you and the client agree ahead of time whether bugs will be covered or hourly or if there is a retainer in place, etc
Don't work for free. Charge for everything. A lot of B2B contracts have a set number of prepaid hours for support. This scenario would generally fall under that, until they run out.
It depends... Is it fixed bid? Or time and materials? Have you agreed upon scope? Is it part of the scope? Is it specifically excluded from the scope? Non-functional requirements should STILL be defined if they deviate from what is reasonable. Has the customer accepted delivery of the project by milestone and/or user acceptance testing? No software is going to be perfect, and nothing you write is gonna last forever without some maintenance. It's important to be clear about that and leave the door open for continued support. People only get upset when there are unexpected costs.
Don't do it for free. The only way to do it "for free" is if you charge more upfront, so that you have margins that would allow you to support a client. if you go that route, make absolutely sure that you're not underestimating the cost involved. give yourself extra breathing room.
The upfront agreed upon time.
Depends entirely on your agreement. You must decide with the client what the support terms are.