For the term to be meaningful, 'bug' needs to be more tightly defined - a discrepancy between the specification (both as stated and intended[1]) and the actual behaviour of the code is a bug. Now, if the wrong behaviour is actually beneficial, then there's nothing wrong with changing the spec, that's basically the central idea in agile - but the idea that if given a spec to make the blue button green, you make the button green - and if users then react negatively to that, then that doesn't mean you shipped a bug in any meaningful sense. It also doesn't mean you shouldn't change it back, quickly, but the developer did not ship a ship.
1: Just because the specification doesn't specifically state "shouldn't crash if the user inputs a negative number", it's understood that the program shouldn't crash given any user input.
Re:Why slow thinking wins
by ScottBurson on Monday July 27, 2015 @03:39AM
(#9953891)
We were working on a compiler for a language developed in-house.
I agree -- different kinds of programming impose very different demands.
I used to work in financial software, where things were very different, and before that I'd interned at a company that did avionics software, which is a whole other ballgame. I just find it interesting that the definition of "bug" can vary so greatly across domains in what's commonly thought of as a single industry.