Idiot Proofing a Program

[avgjane]

Does anyone have a checklist (or something) for idiot proffing a program? I have done a bunch of key catches and some error catching, but the deeper in I got the more I realized I need a list of all the issues to go back and double check.
Also, I'm running a Word MailMerge, and I want to give the users the ability to choose both the main file and the source file (not a problem), except that if they choose poorly, the MailMerge will kickback a gazillion errors. This process runs at night when there is less network traffic, so i don't want errors (do we ever?). I appreciate any insites.
Thanks,
Jane

 

[Foada]

avgjane,

Good luck! The best suggestion I can give you is set a 9 month old baby and a monkey on acid in front of the computer running your app. Every time I try to idiot proof something someone comes up with a better way to crash things. The best success I have had has been with error trapping everything to an error log during beta test to monitor what the joker at the mouse is trying to do. Good luck. Anything is possible, the problem is I only have one lifetime.

 

[cyberbiker]

What I do is get a program working then give it to some of the people who work here to "play" with. They will find ways to break it, then I fix it.
Problem with that, is they have forgotten what they wanted the program to do in the first place after all the design changes.
I also try to disable controls unless they are actually needed at a given time.
ie: If I want "fields open for edit" I disable cmdNew and enable cmdSave when cmdEdit is clicked. things like that.
Also, with message boxes, set the default button to that which does the least damage. ie "Do you want to crash this program", vbYesNo should have the default button set to vbDefaultbutton2.
Additionally, I feel that it is best to minimize the number of choices the user has at any given time (within the needs of the program) For example, I am finally finishing a database program that has at least 73 seperate ways to call reports related to service calls.
The main "search form" is used to select a smaller grouping such as "by technician". This brings up the 3 ways to print by tech.
I know not how others feel on this, but it works here.
Hope somebody has some better ideas. I learn a lot from this forum.
Terry (cyberbiker)

 

[fenris]

Best way to idiot proof a program is to make sure idiots don't use it Seriously, we know that is not going to happen, that is why beta testers are around. I have a friend whos mother makes an excellant beta tester (She still manages to make word and windows do things I have never seen!)

The best advice is to trap everything, even routines that you think are 100% fullproof. Write the (descriptive)errors to a log then analyze the results. Do what windows XP tries to do, when it encounters an error it trys to send a report back home. You could emulate this by a simple email.

Anyway if you figure out a really good way, microsoft and every other software company will be at your door.

Good Luck! Troy Williams B.Eng.
fenris@hotmail.com

 

[cyberbiker]

Just be careful, I wrote an error message that I truly believed no one could ever see. (just a little joke for the other programmers). One user got there. OOPS!
Terry (cyberbiker)

 

[missinglinq]

Used to be a printing company here in town (Richmond Va) who gave away (in the pre-PC era) huge promo posters showing a number of great expressions in various fonts and sizes. The saying I liked best of all was "The problem with making something "Idiot Proof" is that Idiots are so &#$% ingenious !!!"

I usually sit down after I have everything working right and try to apply Murphy's Law. What is must likely to blow the program up? It partially depends, of course, on the type of end users you're developing the application for. "It's got to be the going,
not the getting there that's good!"
-Harry Chapin

 

[mohrorless]

The only way to make a system completely "Idiot proof", is to never give it to the users.

Actually, around here we take turns trying to break each others programs. We pretend to be the users. We don't know how to use the system, do we just pound away at it until something happens. We fix any problems that come from that then as the ultimate test we get a couple of our dumest Cro-magnon () like users and turn them loose on the system for a while. After we fix the problems that they cause, we install the system.

That's when the rest of the users break it.

Good Luck!

John

 

[chiph]

Take a look at a product like NuMega FailSafe. It inserts many statements into your code to log failures when they occur. It's very comprehensive - it gives you a full call stack, line numbers, etc. When you're ready to release, you turn it off, rebuild, and run through another quick cycle of testing to make sure things still work, then ship your product.

Chip H.

OK, couldn't resist adding a joke:

"The difference between genius and idiocy? Genius has its limits."

 

[komputerkorner]

Does anyone know whether a procedure that logs keystrokes and mouse clicks and saves them immediately, will successfully log the last keystroke or mouse click just before an error occurs? If this is possible, then the user could just mail the log back to the programmer and the programmer would know exactly what happened.

 

[CasperTFG]

Remember there are 2 ways to program.

1) To make the program so simple that there are no flaws.
2) To make the program so complicated that there are no flaws.

A program like art is never completed, only abandoned until the next release. Craig, mailto:sander@cogeco.ca

Remember not to name the Lambs...
It only makes the chops harder to swallow

 

[avgjane]

Thank you for all your help! While normally I'm a perfectionist, I've decided that while the idiots are growing leaps and bounds, my program will have some special (un documented) features. I'm not sure what they are yet, but I'm sure I'll get the phone calls. In the mean time, I appreciate the input!

 

[Alt255]

I'm not sure that we serve our own best interests by writing idiot proof programs. I used to spend a lot of time reenforcing my apps with titanium girders... and where did it get me? Some customers call me once every two years and then it is only to request additional features. My income from product support has dwindled to nothing.

Write an idiot proof program? Never again. I will only write programs that perform "as advertised". Insurance for "monkeys on acid" will cost extra.

 

[cyberbiker]

I do not mind the changes since I am on salary and I actually enjoy programming (unfortunately, I have had to do a lot with VBA in ACCESS 97). But when I give them exactly what is requested and they do not like it, it is not a bug!
At one point, I spent over an hour discussing some design features asked for that were "goofy" at best and downright idiotic if you asked me. I was then forced to incorporate these "features" over my better judgement.
After using the program, the manager looked at another program I had written which was very similar in purpose, but was designed for ease of use AND functionality.
He then complained that the program I wrote him was "full of bugs" !!!!
My job performance is evaluated by people who cannot remember what they asked for. Luckily, his boss has some sense and smoothed things over.

It sounds like There have been so good ideas re this subject, but mostly I think we are venting our irritants.

I am a bit more fortunate than many, since I am 50, and have only programmed 3 years. I recall that less than 5 years ago, I was one of the "idiots" breaking programs. I look at what I would have done wrong at that point and try to prevent the user from making that mistake.
Our job is to keep it simple for the user.

If we wade through the venting, some good points have been made. Mostly, I think we need to put ourselves in the users perspective. Terry (cyberbiker)