4 ms·

> But I agree that code is only a bug if it does not do what was originally intended, if the original design was bad, and the code correctly implemented that ba

by sigmaml 11y ago

> But I agree that code is only a bug if it does not do what was originally intended, if the original design was bad, and the code correctly implemented that bad design, there is no bug. The frame of reference for determining if something is a bug or not is the requirement specification, not design. If the design incorrectly or inadequately addresses the requirement, that is a bug as well. There isn't much point in rejoicing over the code that correctly implements an incorrect design!

smegel 11y ago
I think the frame of reference is the programmer intent. If he/she intended to check for equality but wrote: if (x = 42) { Then that is most certainly a bug. If a bit of text was supposed to be blue but came out green, maybe because the person writing the requirements doc got it wrong, it is hardly a bug in the code. The code is doing what the programmer intended, even if that is not what the user wanted. That's why the world has moved on from "bug trackers" to "issue trackers". > There isn't much point in rejoicing over the code that correctly implements an incorrect design! And there isn't much point blaming a coder for correctly implementing an incorrect design, especially if the design document is all they have to go on.
- sigmaml 11y ago
  > I think the frame of reference is the programmer intent. Sure. However, that is secondary. The sort of mistakes that you mention can be caught during code review or unit testing, completely independently of what the actual user requirement is. This post, evidently, does not involve such a case. > The code is doing what the programmer intended, even if that is not what the user wanted. Your perspective appears to be inside-outward. It may be helpful during a performance appraisal, but does the business no good! Edit: inside-out --> inside-outward.
  - drdeca 11y ago
    Could it be that "bug" is defined from an "inside->outward" perspective regardless of whether that is the most useful perspective for the situation?

by sigmaml 11y ago

smegel 11y ago

I think the frame of reference is the programmer intent. If he/she intended to check for equality but wrote: if (x = 42) { Then that is most certainly a bug. If a bit of text was supposed to be blue but came out green, maybe because the person writing the requirements doc got it wrong, it is hardly a bug in the code. The code is doing what the programmer intended, even if that is not what the user wanted. That's why the world has moved on from "bug trackers" to "issue trackers". > There isn't much point in rejoicing over the code that correctly implements an incorrect design! And there isn't much point blaming a coder for correctly implementing an incorrect design, especially if the design document is all they have to go on.

sigmaml 11y ago
> I think the frame of reference is the programmer intent. Sure. However, that is secondary. The sort of mistakes that you mention can be caught during code review or unit testing, completely independently of what the actual user requirement is. This post, evidently, does not involve such a case. > The code is doing what the programmer intended, even if that is not what the user wanted. Your perspective appears to be inside-outward. It may be helpful during a performance appraisal, but does the business no good! Edit: inside-out --> inside-outward.
- drdeca 11y ago
  Could it be that "bug" is defined from an "inside->outward" perspective regardless of whether that is the most useful perspective for the situation?