Loading ...
Sorry, an error occurred while loading the content.

1838RE: [agile-usability] Re: just one bug's enough to make a program useless

Expand Messages
  • Desilets, Alain
    Jan 3, 2006
    • 0 Attachment
      > How can we usabilitists catch these blind spots in design, before they

      > lose us customers?
      > -- Alain:
      > Sorry for late response... Catching up on pre-Xmas break email.
      > By their nature, bugs cannot be caught by design. They can only be
      > caught after the buggy implementation has been implemented. This is
      > of the great advantage of early delivery and TDD....
      > ----

      Looking up to Phlip's original post, I was seeing the bug reported as
      not supporting multiple levels of undo. Then we found there was a
      history panel - an alternatively named feature that accomplished
      similar results to undo. It appears all these features performed as
      the publisher expected - so none of these were bugs. Practices like
      TDD don't catch things like this.

      -- Alain:
      Given the title of Phlip's posting, I was writing with the assumption
      that the reported problem was a bug (i.e. developpers did implement a
      multi-level undo feature but it somehow did not work on Phlip's machine)
      as opposed to a design problem (i.e. feature deemed not necessary when
      it was in fact essential, or feature exists, but is hidden).

      So I stand by what I said. If the problem is a bug, no amount of design
      related work will find it.

      In this particular case, it turns out what Phlip thought was a bug was
      in fact a problem with bad design... The feature existed but it was
      hidden too well. But I have seen cases where a bug makes an otherwise
      well designed software completely unusable.

      The point is this. If you want your software to be usable, you have to
      pay attention to the design, but also make sure that the implementation
      works correctly. And the only way to identify cases where it does not is
      to test the actual implementation continuously through TDD, and also,
      put it in the hands of real test users as quickly as possible.
    • Show all 23 messages in this topic