|
Haha so damn true 
|
|
|
|
|
Every-time the team is about to reach the bug-free (I mean somewhere near) status of the software, the software expands/grows, hence more bugs comes in. No one to blame though.
|
|
|
|
|
Its weasel words to think that software that matches the requirments is bug free.
|
|
|
|
|
Requirements Document
Requirement 1.0.0.1 - Program must crash upon starting.
Success! I finally have my perfect, bug-free software!!
|
|
|
|
|
|
Will never perfect !
I think following lines will explain it properly
1. BUG definition is still undefined, and
2. There was a software saying which reads "Bug free Software is not possible ...until last user Dead"
Happy Bug Fixing 
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
Technically, a single line application can be bug free if it does what it is intended to do. But, that is hardly what is implied.
So.. as complexity arises, so do the opportunities for 'unintended consequences', presumably, some of which are 'bugs'.
To define something as being 'bug-free' should imply: of the code base that is under your direct control...
If you have to incorporate a library of any kind, you just lost control.
|
|
|
|
|
For a simple project, you can have the code bug free. As the project becomes more complex, it becomes much more difficult.
|
|
|
|
|
If claim that your software is bug free, you are not looking in the write places.
|
|
|
|
|
but anything can be compromised. If only cryptographically verified code which was virus checked by a trusted authority can be run on any computer will definitely help a lot.
But I do not see that coming in the forseeable future. For that I do not even need a formally verified system.
The problem is that the errors are now one level above and below. Above is that humans must still define the spec which can introduce security flaws on a higher level. Below means that formally verified software tries to build upon verified buildig blocks which are error free. If one of the basic building blocks contains an error then you have also lost the promise of perfect security.
Formal verification would definitely help a lot but given the high complexity and costs it will aways remain an alien in "normal" software development. To apply formal verification only at outward facing (e.g. network) components will at some point for the sake of practicality soon go into the "normal" code where you still can do bad things.
|
|
|
|
|
Alois Kraus wrote: If only cryptographically verified code which was virus checked by a trusted authority can be run on any computer
Just not the developers, who won't be able to compile & run.
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
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
We just declare all these bugs to be "features" and voilà: no more bugs.
|
|
|
|
|
If you have a good software team, you can get close, but I think it is impossible to write defect free code, especially when it comes to covering all scenarios with complex business logic/rules.
|
|
|
|
|
Go to QA: see how many people are making exactly the same mistakes, over, and over again. SQL Injection, uninitialized variables, finding code online that "might do the job", not thinking even slightly about the code, to not having a clue what they are doing.
And these are the recent additions to the profession. So what chance do we have of bug free code in the future? I'd just be tempted to buy a vintage car, close my bank account, and never fly again... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
With increasing complexity comes the possibility of unexpected outcomes.
For example who could have predicted looking at the primordial slime covering the early Earth that eventually beings would arise to contemplate the origin of the Universe and worry about software bugs.
|
|
|
|
|
and this is why we don't use the word "bug" in our shop anymore. Defect is more fitting, because it encompases errors/issues in business logic, etc.
|
|
|
|
|
I think, it is possible - but now with the first release.
And ... when a software is (nearly) bug-free a new version is released which is not based on the version before ... and soon you get new bugs ... 
|
|
|
|
|
So long we are humans. We can never be perfect. We are prone to making mistakes and we learn by them.
|
|
|
|
|
There are good formal proof kits that can verify correctness.
An O/S kernel that has end-to-end proofs of correctness and security: seL4[^].
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I believe, bug-free software is a very relative term in computer programming, too. It depends on many factors, such as,
1) Features required in the application software.
2) Experience of the programmer writing the software.
3) Tests conducted on the application.
4) Whether the "compiled" part is required or not.
Personally, what I think happens is that a bug is just untested part or feature of the program. By test, I mean, what the output should be vs. what the output was being generated. Testing is just not about a finite set of inputs and outputs, but what the results are when you send a data that is meant to be corrupt — alphabets in a number textbox, SQL injection in data fetching text boxes etc. Bugs removal and bug detection has been confused a lot these years especially by beginners as they consider "Not responding" as a bug (which might be) but mostly (and IMO) bugs are the logical errors in the program.
In the light of what is shared above, I believe we will not get a bug-free software in a foreseeable future.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
...it must be a small command line tool with precisely defined functionality and platform. And even then there're no guarantees, but it can be done. Other than that impossible (at least at this day and age).
|
|
|
|
|
I disagree, see my comment about seL4 (Definitely).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
then (misunderstood and badly applied) Agile and cheap developer-monkeys who are lost without a friggin framework and can kill systems thanks to badly managed memoty (i.e. managed by a brainless system instead of a hopefully not brainless programmer).
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
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
den2k88 wrote: badly managed memoty
Sounds like you need some kind of brainless spell checking framework for that 
I came into this game for the action, the excitement. Go anywhere, travel light, get in, get out, wherever there's trouble, a man alone. Now they got the whole country sectioned off, you can't make a move without a form.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Today I'm mistyping anything, both in English and my native language. It's the Monday effect...
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
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
