Hacker News new | past | comments | ask | show | jobs | submit login

Yup - from a implementation perspective, bug vs feature is a artificial designation.

Where I think it _does_ matter, is when a business wants to track metrics like "# of bugs over time" or "# of bugs per feature".

My team recently got a lot of heat about "a rising number of bugs", and the insinuation was that our code quality was poor. Turns out, > 75% of the "bugs" reported were mis-labeled feature requests or lack of knowledge about how a particular feature was designed to work.




Whoever is giving your team heat about bug metrics needs to read about Goodhart's Law.

There's so many ways to influence number of bugs that it's pointless to measure anything that way. For example, do you make a single bug that lists 15 typos spread around, or 15 bugs (because after all, each typo is a different word and in a different part of the app). Do you accept vague but obviously real bugs while you try to collect enough info over time, or immediately close them as "cannot reproduce"? Is that a bug, or really a feature request?


One way the distinction gets used where I work is to have custom / required fields keyed on the ticket type.

Oh, you want to make a bug ticket in my project? In that case, required fields include "steps to reproduce", "expected result", and "actual result". You want to make a feature ticket in my project? In that case, required fields include "rationale" and "acceptance criteria".


Earlier this year, I reported a bug in Firefox. In my report, I included steps to reproduce the issue, the expected result and the actual result (because I've been on the other side). There were no back-and-forth messages to clarify the issue, and it was fixed in a short amount of time (well, short for a project of that size).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: