I particularly HATE his idea that a program should do what it thinks is right and then appologize later if it is wrong. The latest editions of Microsoft Word do this and they are never right. Instead of me explicitly telling it to do something, it just does it and then I have to waste time undoing its damage and then doing it again correctly (cursing to myself all the while ;-). At this point I have turned off almost everything it does automatically.

I agree it would be nice if the program could fix everything itself, but it has been my experience that this rarely works perfectly. If it is not absolutely perfect, it becomes annoying.

The systems I have worked on in the past are generally decision support systems or office automation systems. They perform very complex functions like dispatching repair people with complex sets of skills to fix things that require special skills and equipment. These systems work well a large part of the time (80-90 percent). Rather than taking blind guesses about the others and possibly automatically dispatching people to the wrong jobs, they put these exceptional cases in a queue for an expert to review.

Sorry, I'm rambling. But I think most programs are best thought of as tools that help the user perform a task rather than as things that do the job themselves. Of course, if you really can handle all errors, that's great! I would still have the error handlers present, but the user would never see them.

I believe everything goes back to the design process. The more time spent in this phase usually results in a better product. The design team needs a cross section of managers, programmers and end users. Most programmers, myself included, want to jump into coding and they invest a lot of time finding that their premises were wrong in the end.