Most software is poorly defined to begin with and so the programmer is responsible for figuring out what the program should do in the absence of a spec. That's one class of bug.
Another is when the spec says to do a particular thing, but that thing is wrong relative to what is actually desired by the people writing the spec.
Another is a correct spec but wrong interpretation on the part of the programmer and so the code does what the programmer wanted it to, but not what the spec said it should do.
Another is correct spec and correct interpretation, but an error in the translation from programmer's brain to code.
Another is correct spec and correct interpretation and correct translation to code but some kind of particular underlying problem with the compiler, architecture, OS, whatever that by using a different (but supposedly equivalent) incantation the problem disappears.
The last class of bug I mentioned is incredibly rare, though, so in many cases what you write is what you get. That's not at all the case with many, many other things.
In most engineering you design a thing and the design is as perfect as you care to make it. And then all the quality leaks out translating the design from theory to practice. That's because the physical world is messy relative to mathematical designs. I can specify the length of a part as 1.0000000000" but it's very difficult to make a part that's accurate to more than 1.000", trying to make one that's 1.0000" long means that you have to specify the temperature!
In software engineering or programming, there's rarely an actual design and that's why the quality isn't there. Once you have a "design" (the source code of the program) it gets translated with near absolute fidelity into the "product" (the binary executable). If you design it wrong, well, sorry.
If I make a program and I say that a number should be 1 and I specify it as an int, it's exactly 1.
> Most software is poorly defined to begin with and so the programmer is responsible for figuring out what the program should do in the absence of a spec. That's one class of bug.
This is exactly my point. The fact that the programmer knows what the program should do implies that there exists knowledge outside of the program of what it should do. This knowledge consititutes the requirements, whether they be written or not.
