http://qs321.pair.com?node_id=926767


in reply to Re^10: regexp class (no bugs)
in thread re: regexp class

I'm with JavaFan on this one. If a product is alleged to have feature X and it doesn't, that's a bug. But I think there is some grey area, due to the vagueness of "alleged". On one hand, if the feature set was defined up front, based on specifications from a "customer", and the delivered product doesn't implement one of those features, that's a bug. OTOH, if it's some kind of commercial product, where feature sets are really driven by internal processes, then a "not implemented yet" feature isn't much of a bug. Of course, the term "bug" itself is vague; every stakeholder has a different idea of what "bug" means. To the coder, a bug might only mean code which contains a flaw. To project management, a bug is a certain kind of record in the tracking system. To a customer, a bug is any variance between the spec and the delivered implementation. And so on. Whose opinion matters most?

Also, under test-driven development, missing features are usually actual bugs, by just about any definition. This is particularly true if the "not done yet" feature is depended upon by other parts of the system.

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

Replies are listed 'Best First'.
Re^12: regexp class (no bugs)
by BrowserUk (Patriarch) on Sep 19, 2011 at 16:09 UTC
    If a product is alleged to have feature X

    Alleged? By whom? When? On what basis? And whom alleges that someone alleged that the product had this feature?

    The problem with not intelligently differentiating between missing features and bugs, is that it makes it impossible to prioritise properly.

    A bug is (should be) a higher priority than a missing feature. It is something that prevents an implemented feature from being useful until it is fixed.

    A missing feature is lower priority because if the bugs in the implemented code are fixed, a less featured product may still be useful and shippable.

    And that pretty much addresses your "dependant feature" argument. If an implemented feature doesn't work without an unimplemented feature, then both are miss-categorised. The dependent isn't complete, so is not yet an implemented feature. And the dependency is not a feature, but an unimplemented subset of the dependant feature's functionality.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Alleged? By whom? When? [etc.]

      Exactly right. Hence, there is some grey area, due to the vagueness of "alleged". At least we agree on that point.

      The problem with not intelligently differentiating between missing features and bugs, is that it makes it impossible to prioritise properly.
      A bug is (should be) a higher priority...
      A missing feature is lower priority...

      That's not particularly controversial, but it presumes that "bug" and "missing feature" can always, necessarily, be differentiated. I.e. it's premised upon you being right when you say "a missing feature is not a bug."

      And that pretty much addresses your "dependant [sic] feature" argument.

      It wasn't an argument, it was a mere observation.

      I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.