I'm seriously tempted...

Ray Cassick

Christian Graus wrote:

I bet if that happened, the airline was United.

:laugh: I hear ya' there :)

Ray Cassick

John Cardinal wrote:

it's what the producer of that software does about it that's the really dividing line between good software and crappy software.

I agree. Two things that a SW company does that tick me off: 1) Argue with me that what I am seeing is a bug. Yeah, sometimes I try to use a feature in a way that was not intended, but tome that's still a bug because they LET me use it that way. I have had companies argue with me on this point even when 'my way' causes a crash and program bail. OK, I am doing something you did not intent to have work but guess what, I know know how to make your code crash and burn. At very least you need to NOT allow me to do that anymore. 2) Break something that WAS working by fixing something that was not. Has no one ever heard of regression testing?

My Blog[^]
FFRF[^]

Member 96

Ray Cassick wrote:

At very least you need to NOT allow me to do that anymore.

Yeah, easily 90% of all the programming you do between the beta stage and release stage is firmly in the category of "I never guessed anyone would try to do that" or "What the hell?" :) Protecting users from themselves is critical but one of the most boring and uninspiring areas of work. Breaking something that was working is all too easy to do. It's really not possible to avoid this 100% of the time with a production project of substantial size and complexity. We have testing methods and standard scripts we run through but sometimes stuff gets missed. It's rare and only happened to me a handful of times in all the years I've been at this, but again, if someone reports it you *have* to fix it immediately and get the update out to everyone, not let it slide. A lot depends on the programmer who is doing the bug fix or feature change and their understanding of the effects that their changes could have, I think that too large a project with too many people leads to more of this kind of unintended consequences because people dont' have enough of the big picture to understand the consequences of what they're doing.

"I don't want more choice. I just want better things!" - Edina Monsoon

_Damian S_

John Cardinal wrote:

I never guessed anyone would try to do that

You can sum it up like this: All software would work perfectly if it wasn't for those pesky users!!

------------------------------------------- Don't walk in front of me, I may not follow; Don't walk behind me, I may not lead; Just bugger off and leave me alone!!

El Corazon

Ray Cassick wrote:

I just think that far too many developers just think it is OK to have a few bugs. I take bugs personally to be honest. They are a mistake that I made and reflect on me.

Same here, and I have pushed testing because my error rate has been lower than everyone else. They want to know why, I point to that, as well as other things. Automatic testing to human testing, I prefer to get sample data sets, or real datasets, or a simulator, or the equivalent. I have written simulators for spec-machines, and I have explained to the customer why it doesn't work. All language is interpretive, there are nuances that we believe mean one thing when they mean something else to another, also there are adaptions that are "forgotten" to be sent out to someone. If one person writes a simulator that all sides use, this is good. If someone needs a change the simulator is changed and sent out to everyone with the change, preferrably after a change request is done, and approvals, and notifications to the others the change is coming. But when they write a simulator based on the spec, and I write a simulator based on the spec, not only is there parallel development and wasted energies, but there is also the chance for reinterpretation on either side. That is where bugs can come from. If we both start from the same book, same data, same simululators, etc. then everyone can test on the same systems. Of course that doesn't stop someone from changing the live data at the last minute, but it does try to prevent it, or at least discourage it.

_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

Ray Cassick

:-D

My Blog[^]
FFRF[^]

Ray Cassick

John Cardinal wrote:

their understanding of the effects that their changes could have

This actually brings up a question about available tools. Do you think that there are good tools available to help developers get this bigger picture? Do you think just having a simple call graph that shows the tree of affected functions impacted by changing one is enough? Personally I think that this along with a good Unit testing package/system in place (and a decent design to start with) should be enough to fend off all but the real killer corner cases here.

My Blog[^]
FFRF[^]

Rob Graham

Christian Graus wrote:

were shutting off the plane to reboot the computer

One heck of a power switch on that computer. To restart, turn off airplane...:wtf:

Tim Smith

Ray Cassick wrote:

When was the last time an aircraft guidance system needed to be rebooted mid flight?

More times than you really want to know.

Tim Smith I'm going to patent thought. I have yet to see any prior art.

Member 96

No a call graph isn't enough, you have to *know* what goes where and what is affected by what. As for unit testing I don't believe in it and we don't use it. I believe it's a crutch designed for companies to be able to place far less trust in their developers and free them up to hire very large teams of low talent programmers in an effort to cheaply get software out the door faster. In other words factory programming. In our company we practice what I feel is artisan programming not factory programming, but we pick projects where we can be artisans so my opinion is obviously biased. In all the examples I've seen it used in it is used pointlessly in the great majority of methods / functions and is just a drain on resources and time and gives developers a false sense of security. So much important time seems to be wasted developing the tests, seeing if they are applicable, running the tests etc against a great majority of code that is blindingly simple and if coded correctly and defensively in the first place would not require a test at all under any circumstances. I do believe in something alternative which is special code that runs in debug builds only and make liberal use of that to ensure sanity checks etc where it makes sense in my own code.

"I don't want more choice. I just want better things!" - Edina Monsoon

Pierre Leclercq

Yes that is a very good idea. I think some companies have already done that. The first to come in mind would be Google. They started a search engine company at a time when everyone was thinking it was a saturated market. They did it much better than everyone else... Still the problem at hand does not apply only to software, many companies do not care enough about quality or support.

M RI0

Ray Cassick wrote:

Personally I am getting sick of the mantra 'all software has bugs'. When was the last time an aircraft guidance system needed to be rebooted mid flight?

Very strong comment. I will remember that one! And ofcourse, It's just commercial talk. Maybe it's a hard criterium, but it is possible to deliver software without any bug. throw new NotImplementedException("No signature.");

Lost User

Man...where have you been Gatsby? Haven't seen you around here since your last article on missile tracking and moving targets.

Gary Wheeler

M@RI0 wrote:

it is possible to deliver software without any bug

No, it's not, except for trivial cases. The phrase "without bugs" implies a lot of things. For lack of a better definition, it means software that can be formally proven correct. Any application of meaningful size can't be proven correct. Similarly, even trivial applications that run under existing operating systems can't be proven correct, since you have to prove the environment correct as well. If you define "without bugs" as "software that isn't immediately lethal to the end user, or even better, doesn't get us sued in court", then sure. There's plenty of bug-free software out there.

Software Zen: delete this;

ghle

Rob Graham wrote:

One heck of a power switch on that computer. To restart, turn off airplane...

Either we were on the same United flight, or it happens more than occasionally. Seriously, all power to the plane was shut off. Totally quiet, no lights, no air, no engines. IIRC it was the guidance computers. After a couple of minutes, fire up the engines and we're good to go. I remember saying, a little too loudly "Must be running Windows.":omg: I thought it was funny. Half the passengers in front of me turned around. It was obvious from the stares of disbelief that no one else found it humorous. :-O

Gary

ghle

_Damian S_ wrote:

if it wasn't for those pesky users!

Hence, long live COBOL and command-line interfaces!!! :-D Contrary to popular beliefs, it IS possible to write bug-free software. It is difficult, but not impossible. With increased (or reduced) complexity comes bugs. bool WasteTimeAndSuckCycles() { bool bWillNeverHappen = TRUE; int i = 0; while (bWillNeverHappen) { // Warm up the CPU // Wait for CPU Power-off i++; } return (bWillNeverHappen); }

Gary

ghle

Gary Wheeler wrote:

M@RI0 wrote: it is possible to deliver software without any bug No, it's not, except for trivial cases.

Sorry, Wheeler, you've been listening to Billy G. too much. It is possible to write bug-free software. The software must do everything it is supposed to do, and nothing it is not supposed to do (the more difficult proof), including allowing for unanticipated situations. As a developer, it is not my responsibility to validate the O.S. or the complier/linker/assembler, however, the application must operate correctly under the O.S. that I qualify it for. Example, if an O.S. (bug) stops sending the application mouse clicks, that is not a problem with the application (that would appear to hang). If the compiler is wrong, again it is not a problem with the application. (Writing in machine code can alleviate compiler problems.) The difficulty is that formally proving software is correct is typically more time-consuming than the application/system development time. We attempt to reduce bugs by applying whatever testing we can, however, there comes diminishing returns. How much testing is done also, in the business world, depends on the "lethalness" of the software. If an application/system can kill/maim people or destroy equipment unintentionally, testing is generally more thorough than if the downside is our spell-checker misses some spellings. Also, having the software do self-checking takes CPU cycles and can make a system less responsive. Multi-processor CPUs can allow software to be more reliable at run-time with no degradation in performance. One thread tests the gozeins and gozeouts while another thread runs the logic. The logic thread returns expected results only if the checking thread finds no problems. Has ANYONE ever found a bug that after-the-fact given the resources was impossible under any means to find? No! We have an aha moment. Once found, we can add additional testing to find that bug in the future (or not). The problem is that we need to *think* about these situations at development time and incorporate them into the application.

Gary

Big Daddy Farang

ghle wrote:

Hence, long live COBOL and command-line interfaces!!!

I agree 50 per cent. Command-line interfaces rock. COBOL not so much. ;) Actually we could replace COBOL with a myriad of other languages and have that same "discussion." For example, "VB" or "C" or ".NET" or "Java." So let's leave at, "To each his own." By the way, you have a compiler warning. It should be: bool bWillNeverHappen = true; Best regards, BDF

ghle

To each his own - agreed. Another thread discussed the desire to kill COBOL, just another reason why we can't.

Big Daddy Farang wrote:

By the way, you have a compiler warning. It should be: bool bWillNeverHappen = true;

Note: I do NOT have a compiler warning, you do. It compiled and executed just fine.:wtf: From afx.h // Standard constants #undef FALSE #undef TRUE #undef NULL #define FALSE 0 #define TRUE 1 #define NULL 0

Gary

Big Daddy Farang

Hi Gary, I sit corrected. It is indeed I who has the compiler warning. I know that with VC++ 6 that would compile without warning. Your original code would be bool bWillNeverHappen = 1; after preprocessing. C++ allows assigning an int to a bool and doesn't complain. However, either of these would be more correct: BOOL bWillNeverHappen = TRUE; // BOOL is #typedef int bool bWillNeverHappen = true; Why have nits if you can't pick them? :laugh: BDF