1581 1845 1999 1138 1907 1028 1765 1011 1461 1167 1535 1028 1285 1732 1154 1066 1525 1498 1303 1881 1333 1832 1394 1812 1212 1374 1613 1219 1772 1593 1247 1491 1766 1340 1154 1873 1592 1197 1380 1710 1002 1509 1855 1723 1050 1906 1578 1871 1742 1505 1407 1589 1531 1092 1375 1715 1314 1889 1541 1256 1603 1857 1958 1455 1155 1532 1123 1653 1137 1286 1182 1072 1849 1194 1341 1050 1861 1933 1598 1679 1237 1450 1407 1673 1891 1421 1720 1116 1938 1346 1041 1627 1200 1465 1279 1355 1206 1189 1581 Bugs Occam’s Razor | PHPnews.io

PHPnews.io

Bugs Occam’s Razor

Written by Yegor Bugayenko / Original link on Mar. 29, 2022

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.

game-of-thrones.jpg
Game of Thrones (2011–2019) by David Benioff

Let’s say I design a simple imperative programming language and you submit this bug report to me:

Here is my code:

a := 7
a := a + 5 - 3
a := a / 3
print a

It doesn't work as expected. It prints 4, 
but it should print 3.

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?

mqdefault.jpg
M190: Make sure the bugs you report explain the simplest possible scenarios; 4 April 2022.

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 is my code:

a := 7
a := a - 3
print a

It doesn't work as expected. It prints 7, 
but it should print 4.

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

calevans yegor256

« Reflection Means Hidden Coupling - Using an SSH tunnel to connect to your dev MySQL with Docker »