4 ms·

I will suggest that bugs and features are not as different as most people think. In both cases you are adding functionality that is not present in the current

I will suggest that bugs and features are not as different as most people think. In both cases you are adding functionality that is not present in the current implementation. The difference is that in a feature, nobody expects the functionality to exist. In a bug, people expected the functionality to exist (either because it existed in a previous version, or because it was thought to have been implemented and it turns out that it wasn't). People react badly to bugs because they feel it is a result of a mistake -- developers broke something they shouldn't, or they didn't do a good job in a previous implementation. The feeling is that a bug has the highest priority, but in reality, there is no such connection from "previous mistake" to "important now". If the only difference between a bug and a feature is that a feature is not expected to already be present, as soon as you discover a bug it becomes a feature request -- we now know that functionality is not present. It should be prioritised in exactly the same way. The key to solving the problem posed by the article is fairly clear. Get a list of all the things the you are not going to implement. Remove them from the list. Done. Whether these are bugs or features is irrelevant.

joepvd 11y ago
I agree with you. One notable difference between a bug and a feature is who will pay for development/testing/support time.
- zer00eyz 11y ago
  This is huge. A capital expense can be amortized (feature dev falls firmly in this category) where a defect (typically) ends up in operating expenses. Many devs are blissfully unaware of the influence accounting (the other nerds) has on an organization. Lots of PM groups are driven almost exclusively by "new features" and poor estimates on their value. I have been hard pressed to find a PM that will do a one week project that adds 100k to the bottom line over a 10 week one that adds 500k even though the former has a better ROI.
sandal 11y ago
Good insight. I didn't split the categories for the report (nor did I distinguish in the essay) for pretty much exactly this reason.
tajen 11y ago
Another difference is that we can evaluate how long a feature will take. The biggest category of bugs can't be evaluated because their origin is unknown, and by the time the developer has found the problem, they might as well solve it than push them in a planning.

joepvd 11y ago

I agree with you. One notable difference between a bug and a feature is who will pay for development/testing/support time.

zer00eyz 11y ago
This is huge. A capital expense can be amortized (feature dev falls firmly in this category) where a defect (typically) ends up in operating expenses. Many devs are blissfully unaware of the influence accounting (the other nerds) has on an organization. Lots of PM groups are driven almost exclusively by "new features" and poor estimates on their value. I have been hard pressed to find a PM that will do a one week project that adds 100k to the bottom line over a 10 week one that adds 500k even though the former has a better ROI.

sandal 11y ago

Good insight. I didn't split the categories for the report (nor did I distinguish in the essay) for pretty much exactly this reason.

tajen 11y ago

Another difference is that we can evaluate how long a feature will take. The biggest category of bugs can't be evaluated because their origin is unknown, and by the time the developer has found the problem, they might as well solve it than push them in a planning.