- When your device is in use in the field, the user will be too hot, too cold, too windy, too dark, too tired, too wet, too rushed, or under fire. Mistakes will be made. Design for that environment. Simplify controls. Make layouts very clear. Military equipment uses connectors which cannot be plugged in wrong, even if you try to force them. That's why. (Former USMC officer.)
- Make it easy to determine what's broken. Self-test features are essential. (USAF officer.)
- If A and B won't interoperate, check the interface specification. Whoever isn't compliant with the spec is wrong. They have to fix their side. If you can't decide who's wrong, the spec is wrong. This reduces interoperability from an O(N^2) problem to an O(N) problem. (DARPA program manager.)
- If the thing doesn't meet spec, have Q/A put a red REJECTED tag on it. The thing goes back, it doesn't get paid for, the supplier gets pounded on by Purchasing and Quality Control, and they get less future business. It's not your job to fix their problem. (This was from an era when DoD customers had more clout with suppliers.)
- There are not "bugs". There are "defects". (HP exec.)
- Let the fighter pilot drive. Just sit back and enjoy the world zooming by. (Navy aviator.)
Aerospace is a world with many hard-ass types, many of whom have been shot at and shot back, have landed a plane in bad weather, or both.
“We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error).”
- Edsger Dijkstra, EWD 1036
Tester at work calls them “defects”. Mostly they are “test findings” resulting from hallucinated specifications that don’t exist except in his mind, or misunderstandings from him not reading the documentation. Or data problems. It’s annoying having them called “bugs” let alone “defects”.
I think for many people “Bug” can imply something that crawled in from outside and messed up the system, “defect” implies that there was an avoidable deficiency in the specification or the implementation. The engineering mindset might prefer “defect” since it implies that we can fix the process and improve the quality of future products, whereas “bug” implies these things are just a fact of life and you can’t expect to eliminate them
I’ve started using “defect” instead of bug for these reasons. The “bug” euphemism implies the software was once correct, but then problems crawled in from somewhere external to infest the otherwise good software.
That’s really not how 99% of software problems happen. They are defects because the software was defective from the moment it was conceptualized or typed in.
“Bug” tries to soften/downplay the developer’s role in producing a defective program.
A bug is a computer program behaving unexpectedly. It can be caused by a defect. It can be caused by a bug crawling into the wiring and making the hardware malfunction. It can be caused by a cosmic ray flipping a bit.
A defect in a computer program is a place where the computer program that does not instruct the hardware to perform in a way so as to do what the program is intended to do.
Given the current (poor) state of our software, most bugs are defects, but not all. Sometimes it really is a bug shorting out a path on the motherboard causing the computer to not do what it was told to do.
Whether or not most defects are bugs is very case specific. Sometimes they're bugs. Sometimes they're just features that haven't been implemented yet, causing the computer program to not do what it is intended to do in an expected, rather than an unexpected, fashion.
A “bug” is specific to computer systems. It traces back to a literal bug (moth) trapped in a relay and is an external factor with no responsibility attributed.
A “defect” is a declaration that something is evidently faulty with a clear onus on the vendor to fix.
A defective device in my mind would have some obviously fatal flaw - it wouldn't even start up, parts would be broken and dangling off, etc. QC immediately rejects it and it doesn't get incorporated into more complex systems.
A buggy device is much worse for any critical application - it appears to work under inspection, and even limited testing, but 1% of the time it develops some fatal data race condition that causes it to fail erratically and cause havoc, e.g. the Therac-25.
So buggy is a subset of defective but it's even worse?
Defects in, eg, pressure vessels can be hard to spot and then suddenly explode when the product is used — sometimes only after a period of seemingly normal operation.
The difference is that a bug implies that it is an outside influence, a defect is something that has to do with making the thing in the first place. A bug you can see as happenstance, a defect implies liability. Huge difference.
I guess I've over-corrected in the other direction. All of the "bugs" I've ever dealt with were caused by engineers, so perhaps the original meaning (similar to "glitch"?) was lost on me.
The word comes from an insect that got caught in the wiring of one of the earliest vacuum tube computers. This caused the thing to malfunction and removing the insect became 'debugging'... the rest is history. I think it's a fun term but defect is far better for the man made software issues.
- When your device is in use in the field, the user will be too hot, too cold, too windy, too dark, too tired, too wet, too rushed, or under fire. Mistakes will be made. Design for that environment. Simplify controls. Make layouts very clear. Military equipment uses connectors which cannot be plugged in wrong, even if you try to force them. That's why. (Former USMC officer.)
- Make it easy to determine what's broken. Self-test features are essential. (USAF officer.)
- If A and B won't interoperate, check the interface specification. Whoever isn't compliant with the spec is wrong. They have to fix their side. If you can't decide who's wrong, the spec is wrong. This reduces interoperability from an O(N^2) problem to an O(N) problem. (DARPA program manager.)
- If the thing doesn't meet spec, have Q/A put a red REJECTED tag on it. The thing goes back, it doesn't get paid for, the supplier gets pounded on by Purchasing and Quality Control, and they get less future business. It's not your job to fix their problem. (This was from an era when DoD customers had more clout with suppliers.)
- There are not "bugs". There are "defects". (HP exec.)
- Let the fighter pilot drive. Just sit back and enjoy the world zooming by. (Navy aviator.)
Aerospace is a world with many hard-ass types, many of whom have been shot at and shot back, have landed a plane in bad weather, or both.