Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Sun, 15 Jan 2012 08:39:14 -0600 Date: Sun, 15 Jan 2012 06:39:11 -0800 From: Patricia Shanahan User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: please coin a term for a lower order bug References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Lines: 50 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 75.11.53.36 X-Trace: sv3-BfszfFTJ8OofEg6Pky7O8qKFg4W+QLv2if1if0sWpk39MO35w1wif6oiB54b0lKltMQ1tLlVOfJfxGy!H8zX8+agRv1ei7cq2jeSm8y6oxehaHKcQOewgecmMfsfV/fWFUuYqUVuUKZc28S2nsAFbqZPQV36!OpS36Ain9JiVwoOIRye440mcCcO1gfCmkZ4AzrHv+Tg= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3613 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11341 On 1/15/2012 5:39 AM, Eric Sosman wrote: > On 1/15/2012 7:21 AM, Wanja Gayk wrote: >> In article, noone@lewscanon.com says... >> >>> A bug is a bug. >> >> If something runs correctly, but slower than necessary, but still >> acceptable, how can it be a bug? > > As a preliminary, let's note that the phrase "but still > acceptable" was not part of the bug description until you added > it. With that in mind, on to the story: > > In 1981 I was peripherally involved with a system that did > interactive searches of a newspaper's content. (If that doesn't > sound remarkable, take note of the era: Before Google, before Yahoo, > before Altavista, before the Web itself, before the first IBM PC.) > One gang of PDP-11 computers handled the searching, and another gang > digested the newspaper's daily data flow and updated the indices. > > At one major metropolitan newspaper, the system was running > smoothly and doing its job pretty much as intended. Sure, there > were hiccups, but they did not seriously inconvenience the system's > users or operators. Yet despite the mostly correct functioning, the > installation was an abject failure. Why? > > Because feeding one day's worth of copy through the indexer took > about twenty-eight hours. > I would say that was a definite performance bug - one of the requirements was to process one day's worth of copy in less than 24 hours. Here's another practical example, at little bit further in the non-bug direction. Many years ago, I was working for a computer manufacturer whose customers included an oil exploration consulting firm. Their major resource was people who could interpret seismometer traces. There were several different transformations on the traces, so one work flow had an expert study a trace, choose the next transformation, give it to the computer, then go work on something else for the next few hours or even days. Even if the original task was the expert's highest priority, nothing useful could be done on it. The sooner the transformed data came back, the sooner the expert would have the option of returning to the original task. In that sort of situation there is a minimum acceptable speed, but faster is better. Patricia