What is a bug?
-
Well, a basic business requirement would be that your code can compile into a binary/runnable format. :)
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
Nish Nishant wrote:
Well, a basic business requirement would be that your code can compile into a binary/runnable format
That would not be a requirement of the business. That would be a technical requirement.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
-
Nish Nishant wrote:
Well, a basic business requirement would be that your code can compile into a binary/runnable format
That would not be a requirement of the business. That would be a technical requirement.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
Technical requirements and business requirements have some overlap.
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
-
Very interesting question you pose. Would you track compiler errors in a bug tracking database? I would hope that no one ever has. As soon as I say that then someone is going to say, "what about the people who are writing code compilers?" :laugh: So, since you wouldn't really consider tracking compiler errors as you do other errors they probably should be ignored since you can't build the software to get it running without resolving them. Analogy Time Also, let's see if there is an analogy.... ...suppose the robots that are building the cars in an assembly line malfunction and start painting the cars multiple colors because the car has a design element which sticks out that inadvertently flips a switch as it travels down the assembly line. Would that be a bug in the car? Probably not.
My book, Launch Your Android App, is available at Amazon.com.
If you are working on a C++ template library, you may need to track some bugs that may take a few days to fix :-)
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
-
In the old days, they were considered bugs. So there were 3 levels ; - compiler errors - runtime errors (program crashes) - logical/functional errors (program does not crash but gives incorrect output) Today most people don't consider compiler errors as bugs.
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
You forgot the Visual Studio doesn't (currently) work properly so we need a workaround bug :)
-
I imagine we can all agree that a runtime error (something that blows up the program at runtime) or a logical error (doesn't blow up, but produces the wrong result) are bugs. Of course, there are other categories, like a "performance bug" -- produces the right result but takes too long. In any case... What about syntax errors -- those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code. Would you go so far as to say that syntax errors are a subset of what we call bugs? Or do you think that something can only be called a bug if it manifests when the program is run? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
For some customers, a "bug" is when your software doesn't magically alter its behaviour to adapt to changes in the business requirements which they didn't bother to tell you about. :doh:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I imagine we can all agree that a runtime error (something that blows up the program at runtime) or a logical error (doesn't blow up, but produces the wrong result) are bugs. Of course, there are other categories, like a "performance bug" -- produces the right result but takes too long. In any case... What about syntax errors -- those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code. Would you go so far as to say that syntax errors are a subset of what we call bugs? Or do you think that something can only be called a bug if it manifests when the program is run? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
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.
-
What is a bug? Baby don't hurt me, don't hurt me, no more!
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
I chuckled.
-
I imagine we can all agree that a runtime error (something that blows up the program at runtime) or a logical error (doesn't blow up, but produces the wrong result) are bugs. Of course, there are other categories, like a "performance bug" -- produces the right result but takes too long. In any case... What about syntax errors -- those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code. Would you go so far as to say that syntax errors are a subset of what we call bugs? Or do you think that something can only be called a bug if it manifests when the program is run? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
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 shitty code, that is not a bug, that is just feces, and they probably need to go see a doctor. Just saying... :-D
-
In the old days, they were considered bugs. So there were 3 levels ; - compiler errors - runtime errors (program crashes) - logical/functional errors (program does not crash but gives incorrect output) Today most people don't consider compiler errors as bugs.
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
Here you touch one of the reasons why I dislike interpreters so much. A compiler can automatically detect syntax errors and also some smaller desasters waiting to happen, like uninitialized variables, missing return values or type mismatches. Since you have nothing to run until the compiler is satisfied, these bugs are easy to get rid of and will not be of any trouble anymore. An interpreter will not notice anything until it reaches a faulty line at runtime. The ridiculous amount of testing othat would be needed to get the security of a freshly compiled (and by no means perfect) program simply is not worth it.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
Here you touch one of the reasons why I dislike interpreters so much. A compiler can automatically detect syntax errors and also some smaller desasters waiting to happen, like uninitialized variables, missing return values or type mismatches. Since you have nothing to run until the compiler is satisfied, these bugs are easy to get rid of and will not be of any trouble anymore. An interpreter will not notice anything until it reaches a faulty line at runtime. The ridiculous amount of testing othat would be needed to get the security of a freshly compiled (and by no means perfect) program simply is not worth it.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.CDP1802 wrote:
An interpreter will not notice anything until it reaches a faulty line at runtime. The ridiculous amount of testing othat would be needed to get the security of a freshly compiled (and by no means perfect) program simply is not worth it.
-
I imagine we can all agree that a runtime error (something that blows up the program at runtime) or a logical error (doesn't blow up, but produces the wrong result) are bugs. Of course, there are other categories, like a "performance bug" -- produces the right result but takes too long. In any case... What about syntax errors -- those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code. Would you go so far as to say that syntax errors are a subset of what we call bugs? Or do you think that something can only be called a bug if it manifests when the program is run? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
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.
-
I imagine we can all agree that a runtime error (something that blows up the program at runtime) or a logical error (doesn't blow up, but produces the wrong result) are bugs. Of course, there are other categories, like a "performance bug" -- produces the right result but takes too long. In any case... What about syntax errors -- those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code. Would you go so far as to say that syntax errors are a subset of what we call bugs? Or do you think that something can only be called a bug if it manifests when the program is run? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
An extract from a letter Thomas Edison wrote in 1878 to Theodore Puskas
Quote:[^]
'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! -
Technical requirements and business requirements have some overlap.
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
Business requirements define "what" the system should do, while the technical requirements define "how" the system should met those requirements. And defining the binaries that are output is most definitely a technical requirement.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
-
I imagine we can all agree that a runtime error (something that blows up the program at runtime) or a logical error (doesn't blow up, but produces the wrong result) are bugs. Of course, there are other categories, like a "performance bug" -- produces the right result but takes too long. In any case... What about syntax errors -- those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code. Would you go so far as to say that syntax errors are a subset of what we call bugs? Or do you think that something can only be called a bug if it manifests when the program is run? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
It's unintended behavior that's not a feature. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Marc Clifton wrote:
What about syntax errors -- those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code.
I would say no, that is not a bug. If it is then this is awesome code that simply has a bug that needs to be fixed.
var godObject = new God();
while(true)
{
godObject.DoWhatIsNeeded()
}Thats right, god objects don't even care about semi colons they are rocking it so much. THey just go go go and do what is needed. I got your whole system right here. Can I get paid now? But seriously, no syntax errors are not bugs. A bug is a manifestation (i.e. observation) of a failure in a running system. Yes, this means that if it is not observed it is not a bug. Welcome to quantum physics and the world of programming where one persons bug is another persons feature.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet. The interesting thing about software is it can not reproduce, until it can.
var godObject = new God();
while(true)
{
godObject.DoWhatIsNeeded()
}This is a compilation error... until you go back it add the missing semi-colon.
If it's not broken, fix it until it is
-
I imagine we can all agree that a runtime error (something that blows up the program at runtime) or a logical error (doesn't blow up, but produces the wrong result) are bugs. Of course, there are other categories, like a "performance bug" -- produces the right result but takes too long. In any case... What about syntax errors -- those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code. Would you go so far as to say that syntax errors are a subset of what we call bugs? Or do you think that something can only be called a bug if it manifests when the program is run? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
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.
-
I imagine we can all agree that a runtime error (something that blows up the program at runtime) or a logical error (doesn't blow up, but produces the wrong result) are bugs. Of course, there are other categories, like a "performance bug" -- produces the right result but takes too long. In any case... What about syntax errors -- those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code. Would you go so far as to say that syntax errors are a subset of what we call bugs? Or do you think that something can only be called a bug if it manifests when the program is run? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
I imagine we can all agree that a runtime error (something that blows up the program at runtime) or a logical error (doesn't blow up, but produces the wrong result) are bugs. Of course, there are other categories, like a "performance bug" -- produces the right result but takes too long. In any case... What about syntax errors -- those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code. Would you go so far as to say that syntax errors are a subset of what we call bugs? Or do you think that something can only be called a bug if it manifests when the program is run? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
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 :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I imagine we can all agree that a runtime error (something that blows up the program at runtime) or a logical error (doesn't blow up, but produces the wrong result) are bugs. Of course, there are other categories, like a "performance bug" -- produces the right result but takes too long. In any case... What about syntax errors -- those things that the compiler (or the IDE) detects before you even run the code, and in fact prevents you from running the code. Would you go so far as to say that syntax errors are a subset of what we call bugs? Or do you think that something can only be called a bug if it manifests when the program is run? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
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!
-
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 :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
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
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
