Answer the question
In order to leave comments, you need to log in
Should work on fixing a bug be paid?
Do you think the bug is a developer's cant that he should fix for free or is it a separate work?
On the one hand, a bug is still a cant, although not intentional, but at the same time, to fix it, you will have to do the work and spend some time.
I certainly don't mean when an application doesn't work at all - it's not a finished job. For example, I'm talking about bugs that did not show themselves during tests, but appeared over time under certain circumstances.
Answer the question
In order to leave comments, you need to log in
Hourly work must be paid.
At a fixed price - depending on the situation, but most likely not.
My logic is this:
There are no applications without bugs. There are unfinished applications. But tests are also time and also money. Therefore, you have to choose a balance between spending more time on tests or saving on them, but spending more on bugs in the future.
Bugs can be fixed for free only in extreme cases, when it's just the developer's wildest fuckup.
Of course, this is a jamb of a programmer and he is obliged to fix it, because there is nothing to demand money for the waste products of his crooked hands, since you cannot do it normally.
Another thing is if this is a revision and the jamb needs to be corrected by someone else - then this work should be paid.
I have an agreement with customers - bugs that are discovered during the first 6 months of operation are fixed free of charge.
Bugs are the lot of the developer. If you are a manufacturer of cars, and you have made a batch of cars where the wheel is playing due to a "bug", then the entire batch is discontinued. The destiny of a developer - especially a front-end developer - is to catch bugs and fix them. And there further from how you negotiated everything with your client.
Any work must be paid.
The only question is when.
Either you agree with the customer so that you do everything "in a short ass", saving yourself time, and he - payment for this time. Then further support and correction of the mistakes inevitably made in such a hurry should be discussed separately.
Or you offer him a finished product, the price of which initially includes your time spent on finding bugs during and after work.
Misunderstanding arises when the first is paid, and the second is expected.
That is, on freelance - almost always;)
IMHO, it was TK.
if it does not work as it is written in the TOR - this should be eliminated, since the TOR has already been paid for.
if it doesn’t work the way it is in the TOR and is not described, this is already a refinement, for $$
I usually fix any bugs if it's clearly my fault, no matter how much time has passed. In addition, I noticed that this gives more loyal customers in the future, and this is probably one of the reasons why I have more than 60 percent of repeat orders and good word of mouth.
But probably still more correct - to give only a guarantee for a certain fixed period.
Depends on the contract or agreement. By default, after the acceptance certificate and payment for the product, any work is paid. But the developer, like any other manufacturer of something, can give a "guarantee" for his work and for some period of time engage in "repair" for free.
And there are also political interests, the customer, for some reason, may be of interest to the developer in the future, and in order to maintain warm contact, some make concessions, even with a different previously agreed regulation.
Envy of your contract, there is, roughly speaking, the moment of acceptance of the transfer, after which everything is formally considered to be done on our part and some finishing touches will cost money in any case, whether they are ours or not.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question