Also, how do you justify being paid to create code that has bugs in it... and then being paid to fix them?
A client has asked me this and I'm interested to hear your response. All answers welcome!
The simple fact is that it's cheaper to get it approximately right and fix bugs as they come up then to guarantee no bugs in the beginning.
In my mind, there is no difference, but there are different categories of "bugs".
1. The first the "mistake". In that there is universal agreement that a piece of code does x yet it does y. These are usually trivial and often picked up either prior to ship or in initial testing phases, whatever that may be. In order words as long as you are competent, you will catch and fix 90% of these.
2. The second is where the result does not match the intended result. There are two sub-classes of this bug. a) The spec/directive/customer request is not properly followed, or interpreted in a way that is incorrect. b) The spec/directive/customer request does not exist for a specific component. c) The spec/directive/customer request is incorrectly defined or invalid within the business context.
This second class is where there are more opinions than stars in the sky, and it's also where we differ from building houses and such. Interpreting a customer's intent and desire (even if the customer is you) and translating that into a functional program is one of the most difficult parts of being a programmer.
Mistakes are items that are not clearly defined as a requirement to the client and use cases identified. If your code passes the documented requirement and use cases supplied, then it is a mistake. Further requirements analysis should have been conducted by the client. Mistakes happen as the set of requirements and use cases become very interrelated to make a complex solution.
A bug would be not thoroughly testing the code to pass all identified requirements and use cases.
The dilemma I have previously run into is the balance between client happiness and my own. If you endlessly do free work for the client, they may come to expect it. If you do not, future work may be lost. My opinion would be to go over requirement docs and statements of work with a fine tooth comb, line-by-line. Any holes, plug them. Any questions, clarify them. Make sure the client knows which party owns which set of risks. You should not take 100% of the risk when maybe the client can spend more time identify requirements.
Based on these definitions, the charge for a "bug" is covered by the client, while a "mistake" would be absorbed by you.
There is one disclaimer here, mistakes can results in bugs. If you were unaware of this issue at the onset then you are partly responsible for the bug in a sense. In this case you may choose to offset some of the cost for fixing the issue.
The key to determining where "bugs" and "mistakes" fall is in having a clear requirement/spec document ahead of time. Each party should understand where their responsibility lies and who assumes the risk.