User idiocy

[salvelinus]

In general, how much of your coding is designed for breaking code?
I don't mean catching exceptions, but designing for user errors. We can all design for correct users, but I don't find them very often.
For instance, some employees at my firm use Access to manipulate data. They do so with an Access form that basically presents them with the table they're working on.
They have no problem doing this. But when I show them that they can open the actual table (which is all the macro (ugh!) does when they click a button), they're lost.
I seem to spend a lot of my time dumbing down apps, at least the gui, to accomodate the user.
I guess in some way, this has to be done. But I'm in a situation where I can make incremental improvements to an existing, aging but working system, or redesign the whole system to a better model, with inevitable bugs to be worked out. What's your opinon?

[BradBrening]

In the end - at least from a professional standpoint - we programmers do not (usually) create programs solely for our enjoyment and use. Programs are created to assist users perform certain tasks in an timely manner. Therefore, it is our jobs as programmers to create robust applications that do not break when data in entered into them.

Although it is hardly every feasable to forsee every possible error that may occur, it is a sign of a good programmer that can create a stable application that is useful by many users.

Sure, it takes more time to do, but simple error checking is a fact of life in the programming world. You may expect that the user will enter a numeric value into, say, a textbox. However, if you simply assign that value to a numerically cast variable you are simply asking for trouble:

BAD!

Dim A As Long
A = CLng(Text1.Text)

It is a simple fact of life - no matter what language tool you use to create applications - that half your time will be consumed anticipating and correcting for errors.