

Ask HN: Bugs vs. Mistakes - jv2222

As a developer do you think there is any difference between Bugs and Mistakes?<p>Also, how do you justify being paid to create code that has bugs in it... and then being paid to fix them?<p>A client has asked me this and I'm interested to hear your response. All answers welcome!
======
DanielStraight
"NASA has managed to write bug free code at a rate of about $1000/line. If
you'd prefer to work that way, we can."

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.

------
run4yourlives
It depends on how you choose to define both, really.

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.

------
skennedy
In my opinion, bugs are identified after mistakes are made.

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.

------
jeffmould
In my opinion a "bug" is when you complete the project based on the client's
requirements/spec and a piece does not work as intended. On the other hand, a
"mistake" is when you miss or do something not defined in the client's
requirements/spec that causes the application/site to function contrary to the
client's wishes.

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.

------
towndrunk
I look at them as the same thing. In either case there is a modification that
is going to take place to correct the issue. To error is human and in 17 years
of software development I have never come across a project that didn't have
both mistakes and bugs in it.

