|
|
|
Congrats!
N_tro_P wrote: It is for the most part an unrewarded venture unless you personally make it a reward.
And there-in is the answer for why you're still married and have kids that receive Student of the Week awards -- because to be successful and a role model, one has to make something that might be intrinsically unrewarding personally rewarding.
I appreciate you writing that, I've been struggling with some motivational issues and what you wrote has helped!
Marc
|
|
|
|
|
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
|
|
|
|
|
A bug is the failure of code to fulfill business requirements.
|
|
|
|
|
Well, a basic business requirement would be that your code can compile into a binary/runnable format. 
|
|
|
|
|
Code that compiles, most basicly
Fulfills the contract and stated purpose. client gets what he paid for or sues/bad reviews
Does not cause RISK (data loss, intrusion, etc), again lawsuit risk
|
|
|
|
|
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.
|
|
|
|
|
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 think this is an excellent, succinct answer, though it doesn't completely capture the 'why' of bugs. A bug is a defect that has to be repaired before the program is in some sense perfect. Mandeep8 wrote: A bug is the failure of code to fulfill business requirements.
means the code is perfect if it perfectly fulfills business requirements.
All kinds of run time errors keep the program from perfectly fulfilling business needs, though if the error is handled, the program may continue to fulfill some business needs. A compile error is a bug in this definition, since a program won't run if it doesn't compile. A program may run without error and still not fulfill business needs if it is incomplete or incorrect. This is a defect in design or implementation. Even if the program does exactly what its developer intends, if it doesn't meet the user's needs for which it was created, it may be said to be defective. This last kind of defect in design is the hardest kind for developers to get their heads around. It's not about what you intended, it's about what the user needed.
|
|
|
|
|
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.
|
|
|
|
|
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?" 
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.
|
|
|
|
|
If you are working on a C++ template library, you may need to track some bugs that may take a few days to fix
|
|
|
|
|
I had the misfortune to work with a software development suite, back in my early years (around 1992-93) - where there was a bug in the compiler.
We never exactly figured out the bug - but it manifested itself in a strange way. Basically, the error would only occur at run-time, but the error that was thrown made no sense for the line of code it was thrown at. If you then ran the code with the integrated debugging turned on, and stepped through the code to that line, it would pass just fine, and work as intended.
If - after you exited the debugger - you then executed the code again, no error would be thrown. Only if you modified the code afterward and executed it again, would an error be generated (this time, on a different line, again unrelated to the error being thrown).
We had to track that bug in our bug tracking system, but we never found out what was causing the bug in the compiler. We knew that the object code, though, that the debugger created (likely including the debugging symbols and other cruft needed to make stepping through the code, monitoring variables, establishing breakpoints, etc) worked fine, so as a part of our process at the time, we just included a comment detailing this info at the top of the code, so that we would remember to run a debug on it before shipping it out.
Multiple phone calls and snail-mail letters (the internet wasn't a commercial thing back then) to the vendor of the system went completely unanswered, unfortunately. I ended up leaving the company a year or so later.
|
|
|
|
|
Interesting story.
In theory there are no exceptional cases, but there's always an exceptional case in practice, isn't there?
|
|
|
|
|
You forgot the Visual Studio doesn't (currently) work properly so we need a workaround bug
|
|
|
|
|
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 f***ing 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.
|
|
|
|
|
|
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
|
|
|
|
|
You can look for technical definitions, but they would just become overly complex sets of rules and codicils, but what a bug really is is something that makes a program behave in a way that your customers don't expect it to behave.
Crashing, for example, is not what I would call "expected behaviour", when using a program -- so if it crashes, there's a bug.
More subtly, if you tell a customer that a program will do A and it does B, that's a bug -- but the bug might not be in the code, it might be in the way you explained it.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Is Windows 7's constant attempting to install a differnet version of an OS without consent a bug? It's not expected the behaviour
|
|
|
|
|
Indeed. It is unwanted behavior that is actually built in.
Many would call that malware, and I'd tend toward agreeing with them.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
