Bugs vs Defects

December 12, 2007 | Comments Off

I read and became persuaded by the idea that calling software errors “bugs” is too cutesy and downplays the significance of the problem. On the other hand, as a developer, there are times when my software doesn’t work correctly but it is not my fault. And calling my software defective because the API doesn’t behave as documented (or is undocumented) is unfair. This is something that has vexed me in the course of my job and I finally think I have a reasonable distinction.

A bug is a defect once-removed (indirection, if you like). My software can simulataneously have defects and bugs. The distinction is whether I am responsible for the error. Relatedly, documentation can be defective.

The whole issue seems like a nuance to me and it has not been something I have been comfortable broaching at work but has come up recently in the terminology of some tools we are evaluating. I think the distinction is important but for practical purposes likely to be lost on the folks who are most concerned about the problems (usually not the developer).

An alternate distinction, and maybe an easier one to sell is core functionality versus non-core functionality. The core functionality of banking software is around maintaining transaction integrity: a math error is a defect; a button that is misaligned is a bug; a crash that corrupts the database is a defect; the saved backup on exit not working is a bug. Again, I think this is too subjective and subtle to be useful, but I think it’s at least a distinction that business people could grasp.

No Comments yet

Sorry, the comment form is closed at this time.