Recently I had an unfriendly discussion with a client with him stating that "he can't pay for fixing the bugs in the application that I built for him".
His reason is simple:
He thinks that a bug in an application originates from the author so it should be the author's responsibility to fix it.
Do you share that idea?
I feel that if you and the client work out the project requirements and scope up front, and execute that, then any bugs beyond that are either due to lack of testing, or simply unforseen.
In the case when its lack of testing, the client shouldn't have to pay for it.
When its a bug that no one could see happening, like a requirement that wasn't communicated correctly or simply changing functionality due to user needs, to me that is an added cost.
However, I feel that in your contract you should have a clause when it comes to maintenance. The client can't expect you to slave away at keeping code up to date, secure, and maintaining it day in day out without paying simply because you are 'the author'. Ask him this- when a book comes out in a new edition, is that book free? If a movie you already had on DVD comes out in a Special EDITION DVD, do you get that for free?
You have to establish these guidelines with the client up front so doing business is easier and there is an understanding from both parties when it comes to cost and invoicing.
It's give and take, and its the process of becoming a better developer if you care about your reputation. If you deliver a product that barely works, (and you care about word of mouth)- you need to do everything in your power to rectify the issues in a timely manner for free.
The better you get at planning projects up front, knowing the requirements, and staying in good, constant communication with the team(s) and client will help everything go a lot smoother.
In short, if you are half assing code, don't expect the client will feel they have to pay for it.
If he's paying you to build reliable software, and you deliver buggy software...why should he have to pay you more to fix it (with the exception being functionality that was either neither in scope at the onset of the project or requirements that weren't communicated up front by the client)?
If I buy Microsoft Windows and Microsoft finds a security hole, I'm not charged a fee to download the patch. It is Microsoft's responsibility to fix the bug in the original software free of charge for me.
The same would go with buying a car. Toyota released "buggy" cars. They then recalled the cars and fixed the issue at no cost to the owner.
I agree whole-heartedly with your client. If a builder built you a house but the foundations became unstable because they weren't built correctly - whose responsibility would it be? Certainly not yours.
You do have to draw the line as to "what is a bug." For example if a calculation isn't working correctly because the client changed his requirements on what that calculation should do - then, yes, the client should pay for it because the requirements changed.
This is where making sure you have an exact specification, and a set test sheet (with successful testing carried out and recorded by the client) works wonders.
The programmer is supposed to deliver the product with a reasonable quality. reasonable quality being a term that should be defined when taking the job.
If you keep your end of the bargain and bugs pop up later, then the client should pay. it is maintenance activity. Oherwise, you should work to get the software in good enough shape to be delivered
there is no way to create a software or a script without bugs...
What kind of bugs are you talking about?
Obviously it's the programmer who is creating most of the bugs. Of course there are bugs which are due to buggy libraries or wrong/ambiguous specifications. But since every programmers creates bugs, fixing bugs is part of the development cycle. So the client should pay for it. Perhaps unless it was due to gross negligence on your part. But mainly it depends on your contract. If you are payed by hour then the client should pay it, if you offered it for a fixed price, it's your fault.
Well, he did pay for the application, and that came from you.
This is why we have contracts and written agreements to say who is responsible for what in the development process.
If someone built me a house and then the roof started leaking the first time it rained, I would expect them to sort that out for me and I wouldn't expect to have to pay them for the privilege.
If someone built me a house and then a meteor hit the roof and put a big hole in it so it started leaking, that might be a different matter.
Ultimately there will always be bugs in software and how you deal with them really needs to be agreed with the client in advance- do they want to sign off and pay on the day and you consider the version they signed off on to be working, caveat emptor? Do they want to purchase support as part of the price and have any issues arising fixed by you as they come up? Who is responsible for QA on your work? Do you provide source code so they can take it to another developer if it runs into trouble?
All these things are reasons why you want to have a contract established ahead of time, so everyone knows where they stand.
Hard to answer without more context. If this is an hourly gig and you were rushed through even after warning them that quality and defect rate would become casualties, then you'd be justified in billing to fix bugs. If, on the other hand, there was a flat rate to deliver on a set of requirements, and you have not properly implemented them then you're going to be on the hook for the fix. Of course there are an overwhelming amount of less clear situations in between these two extremes, so without knowing the nature of your arrangement and the nature of the defects, its very hard to give a simple yes or no.
Software in development phases is expected to have bugs. If the company is paying you a monthly/hourly rate to develop the program, then fixing those issues is paid time. If they are paying you an agreed price for the final product, then you're expected to provide a properly working result for that price.
This is generally something that should be something governed by your contract.
One option is that once the client has "signed off" on the deliverable, then anything after that should (from a contractual perspective) be viewed as a modification, regardless of the change being made.
Another option could consider aberrant behavior (i.e. bugs) as part of the original scope, so that even after "sign off" you are contractually obligated to correct the defect.
This isn't a question that we can answer with any authority.
If this is a question asking for advise on establishing such a contract, then no, it isn't reasonable to expect the developer to fix every bug in the software without additional cost in perpetuity.
If this is a fixed-bid contract, then I would go for the first option I presented (after sign-off, it's the client's property and his responsibility to get it fixed; whether he chooses you or someone else to fix it and what to pay them is his prerogative). That being said, if there's a major defect in the system, then it's up to you to determine if the business relationship and potential reference with this client is worth the cost of absorbing (or discounting) the cost of fixing the bug yourself.
If the client is paying for your time (i.e. paying you an hourly rate), then the point is moot, since whatever work you do after "completion" would/should be billed at the agreed upon hourly rate.
The client should have tested the application more thoroughly before accepting it. If the client doesn't have enough knowledge to test, he/she should let it test by someone who does.
Just like in construction work, you let an independent inspector inspect the building, because you as a consume don't know what to look for.
Once the software is accepted and paid, there should be a maintenance contract, so that if any bugs appear (that neither the client and programmer were aware of), it can be fixed, depending on the type of maintenance contract (paid by hour, or monthly fee).
Too many organizations skimp on testing, or any other quality activity. This seems particularly true of small contract development efforts, where a product is delivered to a single "customer". In these cases, code is written quickly, and pressed into service as soon as it is written. Such code tends to be sloppy, poorly designed, and incurs "technical debt." These are also the customers that are most likely to refuse to pay for "fixing bugs", but it is their own development and management process that is responsible for poor quality.
In cases such as these, the programmer should be paid for fixing bugs, but the more likely, and certainly justifiable, response is for the programmer to "bug out."
The key here is how you define "bug". If the bug is a null ref because a dev missed a input check then it should be fixed for free.
If the bug is a missing feature because the customer did not explain his requirements or because of scope/feature creep that should not be done for free unless the deliverable is shrink wrap software being sold to multiple customers.
I have seen customers define bugs both ways.
Before offering an opinion on the origin of defects, it's worth stating that consulting projects are typically either time and materials or fixed bid.
In a time-and-materials arrangement, the client is aggreeing to pay for the time, effort, materials, libraries, etc necessary to achieve the quality desired. In this model, it's somewhat moot to discuss where the original of the defect lies unless the project is outside of its scope or estimated duration and the contract under which the consultant and client are engaged has specific quality metrics that have not been meet and the contract outlines penalities on the consulting party.
In a fixed bid project, the consulting party agrees to complete the project within a certain duration/cost and as such absorbs the cost of fixing any defects that fall within the scope of the effort.
That aside, it's important to realize that defects can originate as the result of many different kinds of mistakes:
Many of these causes are not under the control of the consulting party, and as such it would seem unreasonable to place all of the responsibility to redress defects arising from these issues on the developer. In general, there is an expectation of good faith: developers don't add defects intentionally into the implementation to extract additional charges and clients provide the necessary information and access to staff to ensure that the project can be completed with reasonable quality.
If the project is delivered on a fixed cost basis and you are still in a warranty period, this it is completely the responsibility of he developer. If you are out of the warranty period or if no warranty period was negotiated, it is at the programmer's discretion. Depending on certain factors (how will it affect your reputation, do you want more business from this customer, how much will it cost you to fix the bug), you might still want to do it.
In any case, if the contract was a time and materials (i.e. hourly) contract, then it is the responsibility of the client to pay the programmer for his time. This is based on the idea that if the bugs had been found when the system was first built, it would still have cost the client to have them fixed.
When you build a house you have proven engineering practices and very little flexibility in deviating from the original design. But software is more like an anthill than a house.
Given the number of permutations possible it does not make sense to say that bugs are the authors fault. Clients should specify their requirements and test the delivered software for compliance.
The act of coding itself will introduce bugs. If he doesn't want any bugs, he would do things using a manual process. Almost any computer system can be replicated manually (by hand). It'll be slower for sure, but it's possible. Let the client try to do it that way for a few days and then I think he'll accept that some defects are inevitable because programming is hard.
Just to make things clear.
I think that bugs exist in essence in any application (that don't mean that i don't create a robust software) it just mean that i build it to be robust but that i can't garantee it. So the step of a project is:
I've always found the software development process to be a series of "gives and takes" between the developers and the client.
On one-hand the customer demands that code is bug-free, bug-free being defined by the constraints imposed by the requirements and the work environment.
For example, we wrote a label printing application, and the customer, 99% of the time printed less that 1,000 labels. One day they had an order that required a 1,000+ labels to be printed, needless to say, the printing didn't work as expected. They demanded we fix the problem, at no cost, because this was a bug! We went back and forth, and in hind-sight, it didn't really accomplish much. This was a rare instance, so I just should have bit it, fixed the problem, and attempted to recoup the cost somewhere else, maybe in a future feature.
On the other hand the customer demands that changes be implemented very quickly, one of the benefits of writing a custom software solution. In order to meet these demands we would often have to throw documentation and testing on the sacrificial altar of development. Now some people might say you can't do that ... or you shouldn't do it, and we try not to, but the customer ultimately pays the bills and we have to do what they say! Though, I always let them know that the changes haven't been fully tested, and they are usually quite understanding. In this case, they often are willing to pay for the bugs.
With those two cases in mind, I always strive to have a good and open relationship with the customer, explaining to them the "give and take" of custom software development. Sometimes the customer is just being a jerk, and at that point you need to reevaluate the relationship, other times, they are short on cash or their boss is being a jerk, these are the times to earn some customer goodwill and just fix the issue, free of charge.
Just my thoughts and experiences.
If it's shrink wrapped software, then you should release patches periodically -- for free.
If it's software with some kind of periodic license, then the client should be entitled to patches and support for the duration of the license.
If it's ad-hoc software, then "warranty" is the word you are looking for.
It's all about sensible business practices.
One word I didn't see while reading all the (good!) answers, is Acceptance Testing.
This is one of the things that protect both sides, and is customary in projects, so that both the customer/client and the software author(s) know the system they have delivered has began its operational life phase.
Without acceptance testing, it is usually a vague legal issue. When performing acceptance testing, the customer defines what they wish to test. The system has to perform their actions in a way that was defined in the requirements.
Acceptance testing exists in most types of engineering work. The contents of acceptance testing should be part of the contract, e.g. you should, as a software provider, mention that acceptance tests will be defined by the customer. In rare cases, both parties define the tests. However, you as a software provider may want to inspect them so that the requirements you have, and the acceptance tests, say the same thing.
In case there is a mismatch between requirements and the acceptance tests, it usually means the requirements weren't fully captured, or weren't captured correctly.
Legally, your contract should mention that the system is delivered after it has passed acceptance tests. Before it passes acceptance tests correctly, it is your responsibility to fix it. After the customer signed its approval, or after all tests pass correctly at the production site, the system has been delivered, and any changes would be the customers' to pay.
Regarding the specific type of bugs detected afterwards, I will not repeat what many others said, and I agree with others saying that major bugs should be voluntarily provided by the software provider, but this is just a personal opinion. Acceptance testing is the first barrier to check.
Be careful about that "fix [for free] every bug that might occure in the life time" in a contract. Let's say there is a new OS version on which your program doesn't work. Your client may be thinking that this is a bug in your software and you have to fix it for free! Seems irrational but it's not uncommon thinking. So definitely you have to add a time frame. At least. As others say, "small but forgotten by client features" or even "misunderstanding how feature should work (after tests/RUP iterations)" are not bugs and that should be clear on contract.
All code has bugs in it. Even the greatest programmers with all the testing in the world will have bugs in their code. I would first make sure the client understands the difference between a bug and incorrect logic.
A bug is an error, flaw, mistake, failure, or fault in a computer program. See Wikipedia's definition. An example might be the user clicks to save a product and one of the fields is not persisted to the database. Or a calculation is performed and the result is incorrect.
Incorrect logic is when the clients expects something to happen but it does not. For example when a new product is added the client wants it automatically added to the storefront's latest item feed and given a 10 percent discount code for the first month.
When originally approaching the project you must make sure that the client gets a specification document and it clearly states all logic that will be created. I assume you will have done this, after all you must know everything you are building before costing it and building it. If you have this, when then client approaches you to say they expected the system to perform a certain task, you have a clear document which shows you were never informed of that business rule. This also protects the client as it gives them a check-list for ensuring everything they paid for is provided.
Finally, when the project is released, the client should be served with a 30 day sign off document. This gives them plenty of time to ensure everything is working and all specifications are met. After sign off, any problems with the code can be charged with a maintenance cost or package (unless business relations wish to intervene).
So in response to your question. Bugs will always exists, but the client is wrong to expect you to support his project for its lifetime at no cost. The issue is not with the code, and it's not with the client. It's with the clients expectations and the lack of specification and planning pre development. Sort these out and you should ensure you never have to face the problem again.
You have to understand Bugs can arrise from any stage of the SDLC.
At any one stage so many things can go wrong, you have to define with your client upfront what you are willing for do at what cost. Also show your client that you will give warranty and support at different levels and at different costs. Don't let them portray it as simply fixing bugs, but instead as warranty.
As others have pointed out, there's a difference between someone paying for your time, and someone paying for a finished piece of work.
If someone is paying for your time, then they should understand that fixing bugs is one of the uses of that time.
However, if you've promised someone a working application, then it's your job to deliver it.
Now, there's a certain level of good faith here, and any reasonably-sized application has bugs. Certainly showstoppers mean that you haven't actually delivered what was promised, while at the same time, minor cosmetic issues may be more reasonable to have additional charges for. Also, there's a fine line between "bugs" and "feature requests" that has to be looked at.
But, at the end of the day, there's a communication happening here that's probably even more important than any of these considerations. Your client is telling you that the product you have delivered is unacceptable. This really means that there is a mismatch in the standards that you each have of the delivered product.
Now, if you're not being paid for time, and the delivered product does not do what is promised, you should probably fix the issues - as otherwise, you have not fulfilled your end of the contract.
But if his standards are actually unreasonable, and these are minor issues, you need to decide whether or not his continued business is worth the extra costs of dealing with him. Certainly in the future you should either adjust your estimates appropriately, or more specifically spell out what will be delivered (or possibly include a certain number of hours of minor bug-fixing, etc.). However, some customerrs just aren't worth it.
But before deciding that he's not worth it, also consider network effects and other related issues.
Or, to look at it another way, he is perfectly free to come to you and ask you to do bug fixes at no charge. You are perfectly free to either do them, or say no. You must both accept the consequences of these decisions, however.
This is why you make a detailed requirements doc. Where you clearly state the programs desired behavior given a set of inputs. The more detailed this is, the less likely there would be any discrepancy with any bugs that may arise.
For example if it is clearly stated that this section of the program will take in these values (given a desired set of values) and what it should do with values outside of that range. There is not a lot of room for someone to say that the bug was the developers fault. If the bug is the result of something that was not specified in the requirements doc.
Basically, if you clearly state what the program will do under this set of input values, and the person paying for the program agrees to it it is not the developers fault if bugs arise, and all of the requirements are met. On the other hand, if the program does not function as specified in the requirements doc then it is the developers fault, and they should be fixed.
Of course programmers create bugs, they create functioning software too.
If you get refusal of payment, then you're not under obligation to hand over the software. If you have already handed the software and the customer is refusing to fund bug fixing, then do a little soul searching and determine what is the right thing to do.
The contract may have lent itself to be more time-and-materials. If so, fixing the bugs without pay is only necessary if you feel your reputation is on the line. Otherwise, they paid for your time, and now they are asking for more time for free.
The contract may have lent itself to be more a fixed price contract. If so, fixing the bugs without pay is only necessary if the bug is conceptually a flaw in the original agreed deliverable. Otherwise, it is really an expansion of the scope of work.
So, what did you agree to, delivery of Software for Money or delivery of Time for Money? If you can't clearly answer the question, then you had a poorly thought out contract (and you will have to decide how much effort you are willing to donate to harbour good will before you must be paid (or cut your ties).
A bug can be defined as, "It doesn't work the way I thought it should". The reason for that is generally because the requirements for the feature were not clearly defined or the implementation does not match the specification.
Bugs happen when specifications aren't clear and proper testing doesn't occur. You can create software without bugs, but it requires better project & requirement management.
It can be done, but you must spend more time away from the code.
As someone told me once, "Better to spend three weeks debugging than waste a few hours in a meeting".
Someone cited Microsoft. IANAL but I don't think they must fix bugs (e.g. http://it.slashdot.org/story/10/04/15/1839236/Microsoft-Refuses-To-Patch-Rootkit-Compromised-XP-Machines http://support.microsoft.com/lifecycle/?LN=en-gb&C2=1173 and many others examples).
They fix bugs because it's economically an advantage.
The same should hold for the contractors: after the software is delivered to the client and accepted by the client it should be good in the state it is, any further work should be paid work. It's always better to state this in the contract (perhaps allowing a few months after delivery of free bug-fixing).