|
I asked one of our customers...
"A bug is when one choose to print a summary report and a summary report is printed"...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I always thought of a bug as a flaw in the code implementation (logic) that does not meet the business requirements, as stated earlier by other members.
If someone is writing sh*tty code, that is not a bug, that is just feces, and they probably need to go see a doctor. Just saying... 
modified 5-May-16 16:08pm.
|
|
|
|
|
Marc Clifton wrote: there are other categories, like a "performance bug" -- produces the right result but takes too long
Performance is a feature, not a bug. Remember that software development is driven by one's ability to only pick two out of fast, correct and cheap.
Marc Clifton wrote: those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code
Typos.
Marc Clifton wrote: Or do you think that something can only be called a bug if it manifests when the program is run?
I would tend to agree with that assertion.
|
|
|
|
|
An extract from a letter Thomas Edison wrote in 1878 to Theodore Puskas'Bugs' -- as such little faults and difficulties are called -- show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
It's unintended behavior that's not a feature.
/ravi
|
|
|
|
|
A bug is any unintended behaviour of the application. The intention of the application is defined in the requirements (I may hope)
An application has 2 sides (more?) with unintended behaviour
1) unintended behaviour in the "eco system" aka computer [exobug]
- behaviour that crashes the application itself
- behaviour that crashes the OS and/or other applications
- congests/blocks resources - CPU, memory, disk, network, GUI real estate, thread pool, battery, ...
thereby interfering with other applications and/or the user. (can be acceptable, even the intention)
2) unintended behaviour wrt its intention [endobug]
- generate completely wrong answers,
- generate partly wrong answers, which might be acceptable (we do so with every float operation)
- generate incomplete answers (what is given is right e.g. incomplete list of presidents)
- generate answer too late,
- generate too much information (overcomplete, the answer must be searched in the output)
- generate the right answer when it is not supposed to (legal/permission/credential bug)
A special kind of bug [releasebug] are features not meant to be released (e.g. not paid for)
These can be especially costly when you wanted to patent them.
- update -
And you have bugs that corrupt your input data (or other data on the file system) while generating the correct result. e.g. a photo-editor that saves the modified picture under the source name.
modified 6-May-16 4:10am.
|
|
|
|
|
It's a moth[^]
Elephant elephant elephant, sunshine sunshine sunshine
|
|
|
|
|
The more interesting question is "what do I tell my customers?"
For example, the customer tells you "we want the name of the customer on our invoices." and you build exactly that. Now your customer calls and tells you the software doesn't work as expected. He created an invoice and it's addressed to "Higher Order Programming", but he had expected it to say "Marc Clifton"! "Well," you say "seems like we have ourselves a bug."
However, classifying this as a bug makes it sound like it's YOUR fault (after all, bugs are made by programmers) while actually the specs were ambiguous (he had to specify the name of the person, not the company, a bug in the specs if you will).
Calling the specs ambiguous may insult your customer.
What is the correct thing to say, you don't want to take blame and you don't want to blame someone else?
Perhaps "it seems there has been a misunderstanding, I can change it right away."
Now what if you had made the application to print not any name on the invoice, but the price (where the name is supposed to be). Clearly that's not in the specs and it seems you actually have a bug. Can you tell the customer "we have a bug"? The word "bug" brings with it a negative annotation. Would it be better to tell the customer "it seems I've overlooked something" avoiding the words "bug", "error", "mistake", etc.
I try to avoid the word as much as I can. "You're right, I'll change it right away!" seems like a good thing to say. Hearing you're right is always nice. Hearing that your problem will be fixed right away is also nice. The customer just forgot about the bug altogether and even though your software is buggy the customer is actually satisfied with your services!
Answering your initial question, I don't think a syntax error is a bug, it's simply something you've overlooked 
|
|
|
|
|
Sander Rossel wrote: ow your customer calls and tells you the software doesn't work as expected. He created an invoice and it's addressed to "Higher Order Programming", but he had expected it to say "Marc Clifton"!
I had to deal with something like that recently (I posted about it a few days ago -- the issue came up on how my client was using the "search" feature) -- the response that I often end up giving is "well, right now it works this way" and they learn something new and potentially useful when using other websites/applications, along with "and I see your point as well, I'll make it work that way too." Then they're really happy, and I learn something too -- always remember that my concept of how something should work isn't necessarily my client's!
When you think about it, any training manual is an attempt to coerce the user into the context that's been created, whereas a spec, before any code is written, is an attempt to create a shared and mutually agreed upon context. Usually specs fall short, so there's some adjustment that always ends having to be made later on.
Marc
|
|
|
|
|
I take a slightly different approach, though I agree with others that a bug is something that appears in a running program - things (e.g. syntax errors) that I fix before the program goes anywhere don't count.
For me, a bug is behavior that the programmer didn't intend (or, at least, shouldn't have intended!). Something happens that is not according to the specifications that (s)he understood and was working with. It needs to be fixed asap, and on the developer's dime.
A deficiency is behavior that the designer of the program and/or the person writing the specifications didn't want or intend, but the code correctly represents the design and/or complies with the specifications. While this still may represent bad coding, it may also represent a failure of communication between the designer and the coder and/or between the customer and the developer. Deficiencies usually need to be fixed, and, since it is (IMHO) the developer's job to make sure that (s)he understands what the customer wants, it usually also gets done on the developer's dime.
Some things that get labelled as bugs are really unimplemented features. When the customer sees a preliminary (or final!) version of the program, (s)he realizes that there was something that (s)he forgot to include in the specifications. These are not the developer's responsibility (to pay for), but it can sometimes be difficult to convince the customer of this!
|
|
|
|
|
have scanned some of the replies, i would say BUG is anything causing Unexpected or Unintended behaviour.
Runtime errors can be expected and handled, as such not bug.
but if expecting screen to scroll up when mouse wheel down, and instead does the opposite, that is a bug.
unhandled errors, like the runtime ones you mention are the most obvious, but if documentation says input does not accept numbers, user inputs numbers and it causes runtime error, because code does not safely handle - that is NOT a bug. Bad input.
|
|
|
|
|
|
I took the "Security Quiz"....after clicking on the link and running the EXE it told me I'd failed 
|
|
|
|
|
I don't have the password for the world.
In fact, I'm not even sure my username is registered.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
My password is the last 6 digits of Pi.
It use to be "Mypenis" but the computer said it wasn't long enough. 
|
|
|
|
|
PompeyThree wrote: It use to be "Mypenis" but the computer said it wasn't long enough.
|
|
|
|
|
In terms of guessing passwords I imagine it's not a hard one either 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
ned help plz
i try to login to codeproject but it seem i fail
my user name is Sander Rossel and my password is 123456 and i type it in but noting happen
meby some1 can try for me if it work
plz is urgentz i ned to post in qa!!!!1
thx
|
|
|
|
|
In the spirit of Password Day, I'll reveal that the password for the read-only Administrator account on my ftp server is 'admin'! 
"Go forth into the source" - Neal Morse
|
|
|
|
|
Which one's better? Which one's more secure? Which one better protects company code/data/IP?
|
|
|
|
|
Serve [^]: this should do it.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
|
It seems that Microsoft have broken some MSDN links to blogs.
For example, on the front page of MSDN dev center for Desktop, Desktop Apps[^], is a Recommended link to Software Architecture[^].
Following that gives a nice "Object Moved" page, with "This document may be found here." Where "here" is a link to the following page[^].
Sadly, it all breaks down there - automatic redirection is not working, and there is no link to the actual requested blog anywhere. Over the last week, I've seen 10 or so similar broken links to blogs.
Edit: I guess this is part of MS's "Documentation Improvement Project" I've been reading about all over the Web this week. Of course, all I can say so far is that my opinion is that it's DIP-sh*t.
(I'll fetch my coat).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
There's no link because it hasn't been allocated an address yet. That's what 'scheduled' means. 
I am not a number. I am a ... no, wait!
|
|
|
|
|
Rob Grainger wrote: I guess this is part of MS's "Documentation Improvement Project"
God, it was already bad enough. Please don't tell me that they're "fixing" it the way they've been "fixing" everything else.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
