Author Topic: "On the distinction between a defect and unexpected behaviour"  (Read 176 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 7231
  • Karma: +165/-115
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
In Re: Cross-profile «stereotyped relationship», possibly our favourite Sparxian (shades of Ray Walston in "My Favourite Martian"  ;)), Eve said:
"I'm not going to try to argue the distinction between a bug and behaviour you didn't expect".

I've spent the last couple of days trying to get supplemental stereotypes to work (as suggested by Eve).  I've found a pile of unexpected behaviours! (Surprise, surprise!)  I've also found what appear to be inconsistent behaviours which, as I have often asserted, are, by definition, defects.

Notwithstanding Sparxians may well take a divergent view to we users about whether a specific unexpected behaviour is actually a defect, I feel it would be useful for the user base to come to a common understanding of "the distinction between a defect and unexpected behaviour" (if there is any - which I believe there is).  It would make it better to answer queries from newer users etc.

Anyway, if this is something that would be useful to the user base, I'm prepared to start the ball rolling...

Thoughts?
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

qwerty

  • EA Guru
  • *****
  • Posts: 11121
  • Karma: +262/-246
  • I'm no guru at all
    • View Profile
Re: "On the distinction between a defect and unexpected behaviour"
« Reply #1 on: June 30, 2020, 05:43:38 pm »
I'm out. I just got used to "works as designed". Any "this is a bug" ends up in "gets not fixed". Good luck, though.

q.

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 7212
  • Karma: +83/-10
    • View Profile
Re: "On the distinction between a defect and unexpected behaviour"
« Reply #2 on: June 30, 2020, 05:50:29 pm »
The main point of contention for me is that every user has different expectations, which are often incompatible. Sparx Systems management and developers have another set of sometimes incompatible expectations for how everything works (and they are users too)

I don't have the luxury of considering every report of unexpected behavior to be a defect. Usually when there's a surprising behavior that is intentional I would like to find ways for the UI to aid the user to develop appropriate expectations. It's not always possible or feasible.

In the example thread, we started with a profile that was implemented based on something we didn't author. (It was originally used in UAF but not formally defined there.) There are a lot of things that the existing profile export does, and the choice is either be inconsistent with them and do it "right" or to be consistent with the existing technology and have the new development not quite as refined as we would like. Both ways can be considered a defect. Even upgrading everything that could be done is likely to cause other issues.

I think I'm fairly pragmatic. I'm trying to work with what I have available and help you do the same.
Eve

support@sparxsystems.com

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 7231
  • Karma: +165/-115
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
"There is no such thing as an inconsistently correct system"
« Reply #3 on: July 01, 2020, 03:48:43 pm »
Thanks, Eve, for the input.

But I was considering this in a more abstract sense.  We too have users and I want to try and come up with a conceptual model that allows me to discuss with them (and with Sparx and other suppliers) "what's going on".

Can we all agree that "There is no such thing as an inconsistently correct system."  Thus if we find an inconsistency, then it is some form of defect!  The degree and source of the inconsistency are what we can debate?

By that, I mean that something may be inconsistent at one level but be consistent at another level.  Eve's example is a case in point!  Where this kind of issue comes up, then an explanation of the degree and level of consistency will help the user.  Eve's example demonstrates the "Eric Morecombe paradox"[1]

Getting back to our consistently correct system, when we see a behaviour in one part of the system it is legitimate to expect the same (i.e. consistent) behaviour in other parts of the system.

How does that sound as a starting point?

Paolo

[1] Eric Morecombe was one half of the comedic duo "Morecombe and Wise". His paradox was to put his finger under Ernie's (Wise) chin and challenge him to "Go on; get out of that without moving!"  As you can see, It can't be done.
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 10129
  • Karma: +326/-30
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: "On the distinction between a defect and unexpected behaviour"
« Reply #4 on: July 01, 2020, 04:08:31 pm »
To be honest, I couldn't care less whether Sparx considers something a bug or a feature request.
I find these discussions so very pointless. Only in a situation where you don't have to pay for bugfixes, but you do have to pay for features, I can see why you would need to make the distinction.

In all other cases I don't make the difference at all. They are all issues and they all need to be solved.
I don't see why Sparx admitting something is a bug, or telling me it's a feature request, changes something for me. They will either solve my problem or not, regardless of the bug/feature request status.

Geert

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 7231
  • Karma: +165/-115
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: "On the distinction between a defect and unexpected behaviour"
« Reply #5 on: July 07, 2020, 10:56:18 am »
To be honest, I couldn't care less whether Sparx considers something a bug or a feature request.
I find these discussions so very pointless. Only in a situation where you don't have to pay for bugfixes, but you do have to pay for features, I can see why you would need to make the distinction.

In all other cases, I don't make the difference at all. They are all issues and they all need to be solved.
I don't see why Sparx admitting something is a bug or telling me it's a feature request, changes something for me. They will either solve my problem or not, regardless of the bug/feature request status.

Geert
Yes, Geert, I agree with the view on Sparx.  However, that's not the thrust of this thread.  I still intend to explore the concepts, but for the present - there are more pressing issues (in your terms) that need to be dealt with so we can actually use EA as we intend.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!