Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11196

Re: please coin a term for a lower order bug

Show all headers | View raw

On Tue, 10 Jan 2012 18:17:48 -0400, Arved Sandstrom
<asandstrom3minus1@eastlink.ca> wrote:

>On 12-01-10 08:54 AM, Eric Sosman wrote:
>> On 1/10/2012 5:45 AM, Arved Sandstrom wrote:
>>> On 12-01-09 10:26 PM, Eric Sosman wrote:
>>>> On 1/9/2012 5:02 PM, Roedy Green wrote:
>>>>> What would you call a flaw in a program that had no effect on the
>>>>> results, but needlessly made the program slower or confusing?
>>>>
>>>>      Call them "bugs."  Sub-classification as "venial bugs" and
>>>> "mortal bugs" just reveals the classifier's lack of imagination.
>>>>
>>> True. But until this slow or confusing behaviour violated a business or
>>> technical requirement it's no bug at all. After all, what is "slow"? And
>>> "confusing" to who?
>> 
>>     The fact that the program is being called slow and confusing
>> demonstrates that it is neither "fast enough" nor "clear enough."
>> If the program were satisfactory, nobody would be complaining --
>> but they are complaining, ergo the program does not meet expectations.
>
>Who's "they"? I run into this situation often enough, particularly with

     You know, them.  <BEG>

>respect to application performance. 9 times out of 10 the people who
>complain about slowness haven't measured the current performance,
>haven't any baseline data for the performance of any previous versions,
>and there are zero business/technical requirements that define target
>performance. In the absence of all that the complaint is entirely

     Agreed to here.

>subjective, and there is no defect.

     Not quite.  It may be real but unproven.  You and I want proven.

     And for that matter, it might well seem slower, but not be any
slower.  I have had this happen to me personally.  It is embarassing
to me when I measure to prove my point, and the two numbers are the
same or nearly so.  Real numbers, please.

>I'd be surprised if _you_ set out to "improve" performance without a
>specified, agreed target at a minimum.

     Quite.

>As for "confusing", if it's a trained user of the program who's
>complaining, for some common-sense value of "trained", then maybe I'll
>take the complaint seriously. "Trained" to me means that the program
>_documentation_ is adequate or better, that the user is familiar with
>it, and that if proper operation of the program also requires other
>knowledge (like that of business processes, or of some subject, or of
>some professional occupation) that the user possesses that knowledge.

     And that the user is making a reasonable effort to use the
program.  "It doesn't work!" does not count for much with me when I
can make it work, or when others can.

>I've seen way too many people complain that something is "confusing"
>about an application where they lack any of these prerequisites. I'm
>sorry, but they can go suck eggs until they do their bit first.

     OK, I just said that, too.

>In a more active way you take care of "confusing" by getting user
>interfaces (command line, graphical etc) and use cases and storylines
>out in front of the user community as soon as possible. This should
>happen in requirements at the latest. That's where the prospective users
>have their opportunity to eliminate the "confusing" bits.

     I would also like a solution from the user.  What would solve the
confusion problem?  The answer need not necessarily be detailed, but
"I don't know.  Just make it better." will not do.

>>     Note that some bugs are addressed by means other than changing
>> the code.  We might, for example, relabel the program as "Only for
>> use on big honkin' screamerboxen" or "Not for use by addlepated
>> nitwits."  That is, sometimes the failure to fulfill expectations
>> is remedied by better control of the expectations.  Nonetheless, it's
>> a bug until and unless *something* is done.

     There was an example from decades ago where having some entry
forms which specified the units of measure did the trick.

>I'll agree that it could be viewed as a requirements defect, sure. OTOH,
>if the business signed off on the requirements documents, it's really a
>change request.

     Yes.

>>     (The software purveyors' pusillanimous retreat behing "Not
>> warrantied for any particular use whatsoever" is beneath contempt.)
>> 
>I agree. But I don't think we're talking about that here. I know I'm not.

     I get leery of warranting something considering how vague the
"specs" can be in the first place.

Sincerely,

Gene Wirchenko

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

please coin a term for a lower order bug Roedy Green <see_website@mindprod.com.invalid> - 2012-01-09 14:02 -0800
  Re: please coin a term for a lower order bug Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-01-09 14:18 -0800
    Re: please coin a term for a lower order bug bugbear <bugbear@trim_papermule.co.uk_trim> - 2012-01-10 09:18 +0000
    Re: please coin a term for a lower order bug George Neuner <gneuner2@comcast.net> - 2012-01-10 11:46 -0500
      Re: please coin a term for a lower order bug David Lamb <dalamb@cs.queensu.ca> - 2012-01-10 16:00 -0500
        Re: please coin a term for a lower order bug markspace <-@.> - 2012-01-10 13:38 -0800
          Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 15:14 -0800
      Re: please coin a term for a lower order bug Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-01-10 18:01 -0800
    Re: please coin a term for a lower order bug markspace <-@.> - 2012-01-10 08:52 -0800
      Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 17:52 -0800
        Re: please coin a term for a lower order bug Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-01-10 19:44 -0800
          Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 20:35 -0800
        Re: please coin a term for a lower order bug Roedy Green <see_website@mindprod.com.invalid> - 2012-01-11 10:54 -0800
  Re: please coin a term for a lower order bug Ian Pilcher <arequipeno@gmail.com> - 2012-01-09 17:29 -0600
  Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-09 21:26 -0500
    Re: please coin a term for a lower order bug glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-10 02:43 +0000
      Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 07:01 -0800
        Re: please coin a term for a lower order bug Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-11 03:23 -0600
        Re: please coin a term for a lower order bug Wanja Gayk <brixomatic@yahoo.com> - 2012-01-15 13:21 +0100
          Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-15 08:39 -0500
            Re: please coin a term for a lower order bug Patricia Shanahan <pats@acm.org> - 2012-01-15 06:39 -0800
    Re: please coin a term for a lower order bug Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-10 06:45 -0400
      Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 07:54 -0500
        Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 07:13 -0800
        Re: please coin a term for a lower order bug Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-10 18:17 -0400
          Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 15:23 -0800
        Re: please coin a term for a lower order bug Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-11 03:30 -0600
          Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-11 08:08 -0500
            Re: please coin a term for a lower order bug Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-11 14:38 -0600
              Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 15:48 -0800
      Re: please coin a term for a lower order bug Roedy Green <see_website@mindprod.com.invalid> - 2012-01-11 11:01 -0800
        Re: please coin a term for a lower order bug glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-12 01:45 +0000
          Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 18:05 -0800
  Re: please coin a term for a lower order bug Jim Janney <jjanney@shell.xmission.com> - 2012-01-10 09:52 -0700
    Re: please coin a term for a lower order bug markspace <-@.> - 2012-01-10 09:51 -0800
      Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 18:08 -0800
        Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 19:30 -0800
          Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 22:11 -0800
            Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 15:52 -0800
          Re: please coin a term for a lower order bug Jim Janney <jjanney@shell.xmission.com> - 2012-01-11 13:38 -0700
    Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 14:05 -0500
  Re: please coin a term for a lower order bug v_borchert@despammed.com (Volker Borchert) - 2012-01-11 20:59 +0000
    Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 15:53 -0800
  Re: please coin a term for a lower order bug Fredrik Jonson <fredrik@jonson.org> - 2012-01-12 06:59 +0000
  Re: please coin a term for a lower order bug Wanja Gayk <brixomatic@yahoo.com> - 2012-01-15 12:45 +0100

csiph-web