Bugs Occam’s Razor
For each accepted explanation of a phenomenon, there may be an extremely large, perhaps even incomprehensible, number of possible and more complex alternatives. The principle of parsimony, also known as Occam’s razor, suggests we prefer the simplest one. For example, “I can’t open the door and can’t attend the meeting” is a description of a problem, which could be reduced to “I can’t open the door” without losing any information, which might be important for those who are waiting for me in the meeting room. I suggest applying the same principle to bug reports.
Let’s say I design a simple imperative programming language and you submit this bug report to me:
Now I have to investigate and find out which operator is broken: maybe the addition doesn’t work, or maybe the assignment, or the division. I don’t know, and I have to debug/test in order to find out… Me. Not you. Why not you?
The more I work with bug reports, the more I believe that this must be your job as a bug reporter, to play with the code and do the best you can to make your snippet as short as it can be to represent the defect.
Of course, you don’t need to do glass-box testing of my code finding the cause of the bug, but on the API surface you must do your job and conclude that the subtraction operator is broken:
Here, you’ve reduced the scope of the defect to a much smaller one. You did your “home work” and found out that only one particular operator in my programming language is broken: the subtraction. You saved my time and increased the chance of your bug report being fixed sooner rather than later.
In general, I believe that this bug optimization work must be done by reporters, not product owners. I would even say that this might be a valid bug rejection reason: the report is not the simplest possible one.
If a bug report is messy or overly complex, who should clean it up before we start fixing it?— Yegor Bugayenko (@yegor256) May 22, 2022