|
As mentioned : Quote: . We'll get close, but never perfect
"
I solved a bug and the application crashed, i have stopped doing that 
|
|
|
|
|
If we build our software with detailed 'blueprints' just like we build bridges and aircraft then we should get similar results. Most software is built with considerably less care than that. The reason is that we have been in a race to achive sophistication. The sophistacation that has been achieved in just a few decades is remarkable but it has been built on layers of software all of which are riddled with bugs. Part of the reason it has been so fast is that during most of this period a software failure was not as catastrophic as a bridge falling down or an aircraft falling out of the sky. There is scope for better. A lot of software isn't just buggy, it is plain stupid and carrying out all sorts of unnecessary and troublesome tasks.
|
|
|
|
|
And even bridges collapse and aircraft going down...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Bridges fall and aircraft crash. The point in here is that we will never create something perfect
|
|
|
|
|
|
It is possible that an old, simple application will became over time bug free. But new solutions for new ideas are actually experiments...As we are talking about new things (for instance, self driving cars) we actually do not know what we are talking about. At the beginning of each project there are some factors (human, hardware, 3rd party software) we not even know of, or measured wrongly...
So, no. No solution for new idea can be bug free... by definition...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I think "bug free" means that every possible even wrong, malicious or attack input data will correctly handled.
That wont happen because of the software is staying fix and the input changes. So problematic input scenarios may arise later in the future. And everybody who has predicted the future was somehow wrong.
So fine and sensible error handling to ensure the "happy path" is best and spitting out everything else.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Companies would rather ship software and fix the bugs later than ship high quality software from the get go. This is a conscious financial decision which has nothing to do with software development. Until that changes then there will always be bugs in the software.
"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
|
|
|
|
|
that translates to ill-fated software.
Peter Leow
https://www.amazon.com/author/peterleow
|
|
|
|
|
Keep it Simple, Stupid - If we'd just all stop being so damn fussy.
Isn't "HELLO, WORLD!" enough?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "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 |
|
|
|
|
|
We can do it right now, but it doesn't come cheap. This article about developing the Space Shuttle's software is always a good read. It was written 20 years ago, but it shows that we can develop error free software given enough time, money, and process.
Now, whether we can create error-free software within the time and budget constraints imposed on typical software developers is a different question entirely. I bet that 20 years ago, anyone you'd have asked would have thought we'd be a lot further down the road of error free software creation than we currently are.
At present, it seems like a large chunk of the industry it diving head first into tools and techniques that result in more bugs, not fewer. It could just be that consumers have demonstrated a preference for faster iterations of software with new shiny bits added as quickly as possible, regardless of the quality of the resulting product. So maybe the world isn't getting the software it needs, but it is getting the software it deserves.
|
|
|
|
|
I have seen people describing some software applications as perfect and I ask them why made them think so!
Two common replies I receive is that it does its part perfectly and user has not changed requirement after certain release.
But, then these are smaller systems that know exactly what do to and don't multitask.
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
Tell your manager, while you code: "good, cheap or fast: pick two. "
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
