Why is software so bad...
-
Why is software so bad... "...its lack of design. Microsoft’s popular Visual Studio programming software is an example..." “The attitude today is that you can write any sloppy piece of code and the compiler will run diagnostics,” says SRI’s Neumann. “If it doesn’t spit out an error message, it must be done correctly, right?” “Software sucks because users demand it to.”
In 1996, for example, the French Ariane 5 rocket catastrophically failed, exploding just 40 seconds after liftoff on its maiden voyage. Its $500 million satellite payload was a total loss. According to the subsequent committee of inquiry, the accident was due to “systematic software design error” — more precisely, a buffer overflow. WRONG... Morons can't even get their WELL PUBLISHED FACTS STRAIGHT. Ariane 5 failed because of an integer overflow conversion error. The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected. I would love to know what they would have done if they caught the error. Why wouldn't they have done the same an a catastrophic failure. It is this type of exception checking that scares me. In the case of a rocket where it either goes up or it ... goes up. I can see the cross your fingers and pray method of exception catching. But if other subsystems are depending on that routine to be fully functional (which is different than not throwing exceptions), I don't see how catching irresolvable unexpected exceptions would help. Here is basically what the review board said: http://java.sun.com/people/jag/Ariane5.html 1. A software exception shouldn't have ever resulted in the shutdown of the processor. (Which was what was specified. It was assumed that if a processor tossed an exception, it was a HW failure and that the backup unit could take over.) 2. If a software exception does happen, it should be caught and a best estimate be made so that the mission can continue as best it is able. My opinion: Since rockets can't be brought back to the pad to try again if the software tosses it's cookies, it is obvious that what the review board outlined is what should be done. But the difference there is that IMHO, they fully understand the ramification and seriousness of the class of exceptions they are dealing with. These exceptions should have never happened UNLESS there was a specification or design flaw. So, when they do toss an exception, it is understood that chances are the sh*t is already heading toward the f
-
Why is software so bad... "...its lack of design. Microsoft’s popular Visual Studio programming software is an example..." “The attitude today is that you can write any sloppy piece of code and the compiler will run diagnostics,” says SRI’s Neumann. “If it doesn’t spit out an error message, it must be done correctly, right?” “Software sucks because users demand it to.”
Mark Nischalke wrote: If it doesn’t spit out an error message, it must be done correctly, right? A software engineer who believes that should get out of the business of engineering software. I disagree with the insinuation that a lot of software is bad because the tools allow it to be. Let's put the blame where it lies: on the heads of management and engineering teams who, by their lack of engineering discipline, often allow themselves to sign off on inferior products. I've worked in both good and not so good engineering shops. Imho, there's a strong correlation between good engineering practices and the quality of the finished product. I feel that the problem is that management frequently doesn't accept and/or understand that these practices are integral to the development process. Contrary to what management usually thinks, writing software is not the same as making omlettes. If you've made one, you haven't made 'em all. /ravi Let's put "civil" back into "civilization" http://www.ravib.com ravib@ravib.com
-
In 1996, for example, the French Ariane 5 rocket catastrophically failed, exploding just 40 seconds after liftoff on its maiden voyage. Its $500 million satellite payload was a total loss. According to the subsequent committee of inquiry, the accident was due to “systematic software design error” — more precisely, a buffer overflow. WRONG... Morons can't even get their WELL PUBLISHED FACTS STRAIGHT. Ariane 5 failed because of an integer overflow conversion error. The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected. I would love to know what they would have done if they caught the error. Why wouldn't they have done the same an a catastrophic failure. It is this type of exception checking that scares me. In the case of a rocket where it either goes up or it ... goes up. I can see the cross your fingers and pray method of exception catching. But if other subsystems are depending on that routine to be fully functional (which is different than not throwing exceptions), I don't see how catching irresolvable unexpected exceptions would help. Here is basically what the review board said: http://java.sun.com/people/jag/Ariane5.html 1. A software exception shouldn't have ever resulted in the shutdown of the processor. (Which was what was specified. It was assumed that if a processor tossed an exception, it was a HW failure and that the backup unit could take over.) 2. If a software exception does happen, it should be caught and a best estimate be made so that the mission can continue as best it is able. My opinion: Since rockets can't be brought back to the pad to try again if the software tosses it's cookies, it is obvious that what the review board outlined is what should be done. But the difference there is that IMHO, they fully understand the ramification and seriousness of the class of exceptions they are dealing with. These exceptions should have never happened UNLESS there was a specification or design flaw. So, when they do toss an exception, it is understood that chances are the sh*t is already heading toward the f
Microsoft’s popular Visual Studio programming software is an example, to Downes’s way of thinking. Simply placing the cursor over the Visual Studio window, Downes has found, invisibly barrages the central processing unit with thousands of unnecessary messages, even though the program is not doing anything. Ah - here's a man who obviously understands the intricacies of the tools he blithely looks at. Clearly any program with a complex UI such as VS that constantly polls the cursor position in order to update the user with context specific information is rubbish. (Yes, I'm being sarcastic). Until the 1970s, compilers sat on large mainframes that were often booked days or weeks in advance. Not wanting errors to cause delay, coders — who in the early days tended to be trained as mathematicians or physicists — stayed late in their offices exhaustively checking their work. Hmm - and up to the 1970's most programs weren't written to exist in a multithreaded, event driven, distributed environment. I'm fairly sure we could all write rock solid apps if we could assume the program flow starts at line 1 and ends at line 100 and that it has complete control over the CPU for the duration of it's run. Nothing like a bit of arm-chair sensationalist journalism... cheers, Chris Maunder he was a VB programmer, but he got better - Christian Graus
-
Why is software so bad... "...its lack of design. Microsoft’s popular Visual Studio programming software is an example..." “The attitude today is that you can write any sloppy piece of code and the compiler will run diagnostics,” says SRI’s Neumann. “If it doesn’t spit out an error message, it must be done correctly, right?” “Software sucks because users demand it to.”
Maybe we should counter with an article 'Why Journalism is so bad'. Just take a look at the first two words of this article at that precious journalist's news site. cheers, Chris Maunder he was a VB programmer, but he got better - Christian Graus
-
In 1996, for example, the French Ariane 5 rocket catastrophically failed, exploding just 40 seconds after liftoff on its maiden voyage. Its $500 million satellite payload was a total loss. According to the subsequent committee of inquiry, the accident was due to “systematic software design error” — more precisely, a buffer overflow. WRONG... Morons can't even get their WELL PUBLISHED FACTS STRAIGHT. Ariane 5 failed because of an integer overflow conversion error. The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected. I would love to know what they would have done if they caught the error. Why wouldn't they have done the same an a catastrophic failure. It is this type of exception checking that scares me. In the case of a rocket where it either goes up or it ... goes up. I can see the cross your fingers and pray method of exception catching. But if other subsystems are depending on that routine to be fully functional (which is different than not throwing exceptions), I don't see how catching irresolvable unexpected exceptions would help. Here is basically what the review board said: http://java.sun.com/people/jag/Ariane5.html 1. A software exception shouldn't have ever resulted in the shutdown of the processor. (Which was what was specified. It was assumed that if a processor tossed an exception, it was a HW failure and that the backup unit could take over.) 2. If a software exception does happen, it should be caught and a best estimate be made so that the mission can continue as best it is able. My opinion: Since rockets can't be brought back to the pad to try again if the software tosses it's cookies, it is obvious that what the review board outlined is what should be done. But the difference there is that IMHO, they fully understand the ramification and seriousness of the class of exceptions they are dealing with. These exceptions should have never happened UNLESS there was a specification or design flaw. So, when they do toss an exception, it is understood that chances are the sh*t is already heading toward the f
Tim Smith wrote: Ariane 5 failed because of an integer overflow conversion error. Thats true, but I think what they meant (and should have said) by "systematic software design error" is "bad process". The developers of the A5 software used large parts of the software from the A4 without properly testing. They simply didnt have a good enough process for the design, implementation *and* testing of their software. Tim Smith wrote: I know I must sound like a broken record when it comes to exception handling. But I just don't think enough people realize there is a LOT more to exception handling than just a "try" and "catch". Dead right. I havent got it yet, but I want to get "Exceptional C++" by Herb Sutter. It goes into these sort of things.
-
Mark Nischalke wrote: If it doesn’t spit out an error message, it must be done correctly, right? A software engineer who believes that should get out of the business of engineering software. I disagree with the insinuation that a lot of software is bad because the tools allow it to be. Let's put the blame where it lies: on the heads of management and engineering teams who, by their lack of engineering discipline, often allow themselves to sign off on inferior products. I've worked in both good and not so good engineering shops. Imho, there's a strong correlation between good engineering practices and the quality of the finished product. I feel that the problem is that management frequently doesn't accept and/or understand that these practices are integral to the development process. Contrary to what management usually thinks, writing software is not the same as making omlettes. If you've made one, you haven't made 'em all. /ravi Let's put "civil" back into "civilization" http://www.ravib.com ravib@ravib.com
Ravi Bhavnani wrote: Contrary to what management usually thinks, writing software is not the same as making omlettes. If you've made one, you haven't made 'em all. eggselent analogy Ravi !! It really explains it :-) Regardz Colin J Davies
Sonork ID 100.9197:Colin
More about me :-)
-
Maybe we should counter with an article 'Why Journalism is so bad'. Just take a look at the first two words of this article at that precious journalist's news site. cheers, Chris Maunder he was a VB programmer, but he got better - Christian Graus
Chris Maunder wrote: first two words Yeah that journalist sucks, I hate the way journo's pretend to be experts on everything. Regardz Colin J Davies
Sonork ID 100.9197:Colin
More about me :-)
-
Mark Nischalke wrote: If it doesn’t spit out an error message, it must be done correctly, right? A software engineer who believes that should get out of the business of engineering software. I disagree with the insinuation that a lot of software is bad because the tools allow it to be. Let's put the blame where it lies: on the heads of management and engineering teams who, by their lack of engineering discipline, often allow themselves to sign off on inferior products. I've worked in both good and not so good engineering shops. Imho, there's a strong correlation between good engineering practices and the quality of the finished product. I feel that the problem is that management frequently doesn't accept and/or understand that these practices are integral to the development process. Contrary to what management usually thinks, writing software is not the same as making omlettes. If you've made one, you haven't made 'em all. /ravi Let's put "civil" back into "civilization" http://www.ravib.com ravib@ravib.com
The problem is that teams are usually made up of "coders" and "architects" and "managers". None of which have any true responsibility for their actions. Everyone is just following orders, and frequently are forced to write code they don't like or agree with in ways they would never do if they had the choice. Of course,if they had the choice, the project would never be finished because it would never be 'good enough' as Ed Yourdon puts it. -- Where are we going? And why am I in this handbasket?
-
Microsoft’s popular Visual Studio programming software is an example, to Downes’s way of thinking. Simply placing the cursor over the Visual Studio window, Downes has found, invisibly barrages the central processing unit with thousands of unnecessary messages, even though the program is not doing anything. Ah - here's a man who obviously understands the intricacies of the tools he blithely looks at. Clearly any program with a complex UI such as VS that constantly polls the cursor position in order to update the user with context specific information is rubbish. (Yes, I'm being sarcastic). Until the 1970s, compilers sat on large mainframes that were often booked days or weeks in advance. Not wanting errors to cause delay, coders — who in the early days tended to be trained as mathematicians or physicists — stayed late in their offices exhaustively checking their work. Hmm - and up to the 1970's most programs weren't written to exist in a multithreaded, event driven, distributed environment. I'm fairly sure we could all write rock solid apps if we could assume the program flow starts at line 1 and ends at line 100 and that it has complete control over the CPU for the duration of it's run. Nothing like a bit of arm-chair sensationalist journalism... cheers, Chris Maunder he was a VB programmer, but he got better - Christian Graus
Chris Maunder wrote: Nothing like a bit of arm-chair sensationalist journalism... Hmmm, the interesting thing is I just read this same exact article in a magizine earlier today(forget the name now). The author probably thought it was important to get it published in several places, either that or someone likes to copy and paste. Article quotes a person saying: "Software’s simply terrible today" I can think of at least one person who agrees with this, especially as it relates to Oracle products. And yes, alot of commercial software out there is simply no good. On the other hand so is the quality of some articles/books written these days.
-
Tim Smith wrote: If cars were software, they would have 10,000 different features at 1/10 of the cost of the original car. Every few years, cars would develope a totally new engine based on completely new technology. If car were software, there would be about 10000000000 crashes a day. I think I would go by foot (And I'm not sure I would be safe either crossing an intersection will all those 10000-features cars waiting for green light X| ). Michel It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeardMichel Prévost wrote: If car were software, there would be about 10000000000 crashes a day. I think I would go by foot (And I'm not sure I would be safe either crossing an intersection will all those 10000-features cars waiting for green light ). If cars were software we would be driving at about 10000000000 km/h by now... (and continually doubling ever year and a half...) Have fun, Paul Westcott.
-
Michel Prévost wrote: If car were software, there would be about 10000000000 crashes a day. I think I would go by foot (And I'm not sure I would be safe either crossing an intersection will all those 10000-features cars waiting for green light ). If cars were software we would be driving at about 10000000000 km/h by now... (and continually doubling ever year and a half...) Have fun, Paul Westcott.
And once a day the car would blow up - killing all of the occupants. Oh and next year the new cars will require different roads for driving on.:laugh: Dave Huff Igor would you give me a hand with the bags? Certainly - you take the blonde and I'll take the one in the turban!
