Fallacy - a mistaken belief, especially one based on unsound argument. When I first became a software developer more than 15 years ago, I was tasked with helping ship Office 2007 and improving the quality of the product. My manager at the time assigned over 100 bugs to me, and I dutifully fixed those bugs over the next 30 days. I was rewarded well for “saving the day”, but I had no idea to objectively know whether I improved the quality of the product. In a waterfall and boxed product model, you may be able to get away with this approach, but I’ve been surprised to see this pattern perpetuated for software that ships on a faster cadences.
As always great insights D - one thing I have learned is that engg teams should push back on the bug list from PM or customers as there is too much emphasis on “what and how many bugs” and very little clarity on “why” is it a bug. Once we know why it’s a bug we can see the impact of the bug and that helps determine the priority easier than saying all UI or visual bugs are Sev 3. When you see a typo maybe u push it out (I wouldn’t) but if it’s a typo in a product pricing number then it’s not a “typo bug” but a Sev 1 as it has a bigger impact.
As always great insights D - one thing I have learned is that engg teams should push back on the bug list from PM or customers as there is too much emphasis on “what and how many bugs” and very little clarity on “why” is it a bug. Once we know why it’s a bug we can see the impact of the bug and that helps determine the priority easier than saying all UI or visual bugs are Sev 3. When you see a typo maybe u push it out (I wouldn’t) but if it’s a typo in a product pricing number then it’s not a “typo bug” but a Sev 1 as it has a bigger impact.