Re: Template open/save behavior

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hi Jeff:

On 12/2/06 6:04 AM, in article uk#YN4zLGHA.3408@xxxxxxxxxxxxxxxxxxxx, "Jeff
Wiseman" <throwawayacct223@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

I'm one who prefers to call a spade a spade, a bug a bug, and a
"stupid, screwed up, poorly thought out, highly misguided, and
very bad DESIGN DECISION" just that :-)

Sorry :-) The software industry has moved on. Software Testing has now
expanded to include "Static Testing". Static Testing is testing of the
design and specifications and requirements.

So now, a "Bad Design" is a Defect. Poor requirements is a Defect. Poor
specifications are Defects. And Defects are BUGS :-)

It's official: It's an ISO/ITIL/ITSM/OGC/CMM/CMMI/Six Sigma "Standard". If
the requirement is wrong, or the design is wrong, or the specification is
wrong, that's just as much a bug as if the code is wrong.

The vast majority of software defects (and ALL of the real disasters...)
happen before the code is written. That's why the industry has made such a
push into Static Software Testing recently. That's why the majority of the
software testing budget these days will be spent in Quality Assurance
activities that occur before the code is written, or before it's ready to
run.

The connotation of a bug is a flaw that was not intended.

That's correct: But "intended" by 'whom'? Recently we are much clearer on
this: "not intended by the CUSTOMER".

The altered "feature" being discussed was totally premeditated
and spec'ed as such. That puts it into one of the "stupid,
screwed up, poorly thought out, highly misguided, and very bad
DESIGN DECISION" catagories IMHO. Let's give credit where credit
is due :-)

Yes. Sure. But according to all of the QA and Management standards that
are now in use, it's still a bug. We now have a warm and fuzzy feeling of
satisfaction: we know where this particular one happened. Those amongst us
who work as Programmers and Software Testers are utterly sick of getting the
blame for these. For 30 years previously, the hapless coder got the blame
for "everything" that went wrong. This did not lead to a great feeling of
career satisfaction.

Now, we are finding out who is "really" causing these things. Sometimes, it
IS the Customer. For example: The reasons that Words Bullets and Numbering
functions are close to "unusable" could be directly attributed to "The
Customer". They shouldn't be, but they "could" be...

What happened there is that Microsoft performed EXTENSIVE research amongst
users who did not know how to use word processors, or bullets or numbering.
Microsoft asked users who did not know what they were doing what they
"wanted". And that's what they built.

Now we have a very comprehensive proof that people who don't know how to
drive are perhaps not the best people to be designing cars. And people who
can't use word processors are perhaps not the best people to design them.

Also, the term "bug" is kind of cutesy which downplays its
reality as a flaw. All bugs are flaws but not all flaws are bugs.

That is no longer industry accepted practice. In modern practice, they are
ALL "Defects". "Bug" is simply the colloquial term for "Defect".

The exact nature of a flaw can usually be ascertained by what
level of the company you need to go to to get it corrected. If
you go to the programmer that wrote the code, show it to them,
and they say "Shoot! I gotta fix that!" and they scurry away to
their terminal, then it is likely a bug. If they say, "Oh, Im
sorry but you'll have to submit an ECN to the VP of marketing,
have it approved, submitted to the change control board, and
written in for release in two years, then it was likely a stupid,
screwed up..., oh well you get the picture! :-)

Defect = True, Severity = 1, Cause = "Feature Specification"

Thanks to one and all for letting me get that pet peeve out, I
have a low tolerance for poorly spec'ed and designed software
regardless of who does it (myself included).

Yeah. Me too... I just completed yet another stint working for the
Software Testing department of a major corporation, so this stuff is top of
mind to me: particularly the bits about bad specification :-)

Cheers

--

Please reply to the newsgroup to maintain the thread. Please do not email
me unless I ask you to.

John McGhie <john@xxxxxxxxxxx>
Microsoft MVP, Word and Word for Macintosh. Consultant Technical Writer
Sydney, Australia +61 (0) 4 1209 1410

.

Relevant Pages

  • Re: OT: Exchange (Was Re: OpenVMS - When downtime is not an option)
    ... application bug to provide access to protected data and/or provides ... the bugs *only* affected Exchange Server. ... Server* design flaw, not a Windows flaw. ... Microsoft product and those same designers and programmers have probably ...
    (comp.os.vms)
  • Re: pppd crashes, was: kde-freebsd
    ... User PPP is very easy to use, Kernel PPP is not. ... It appears to me that PPP is the more normal way on FreeBSD, whereas, in my own experience Linux, prefer PPPD. ... Over time FreeBSD and Linux drifted apart on this design issue, and it became something of a characteristic of BSD, perhaps that is why Kernel PPP became less well maintained ... Regarding the various comments by Michael Nottebrock, Firstly: The bug you mentioned I have not experienced. ...
    (freebsd-stable)
  • Re: Off switch blues
    ... it's not a feature it's a bug. ... like, consider a design bug. ... sleep, close the lid, and unplug the keyboard, it's because I intend to ... I don't intend for it to wake back up until I open the ...
    (comp.sys.mac.system)
  • Re: What Happened to Grundig?
    ... improve the original Sony design. ... Regarding how Grundig came to use the Sony design, ... Correcting the bug only realizes what the design ...
    (rec.radio.shortwave)
  • Re: c / c++ : is it end of era ?
    ... That's not a bug. ... It's a design decision. ... If you want a super-handholding, ultra-safe language, they are out ... hence he is not a C programmer. ...
    (comp.lang.c)