What is a nicer way of describing the process of “Idiot Proofing” a piece of software [closed]

Question

To me, Idiot Proofing just means making sure the user can't break a piece of software even if he tried. For instance, if a value is read from a text box, and is converted to a double, if the underlying software is idiot proof, it won't break if the user types in a non-double value.

I recently wrote up a development schedule and one of the items was named "Idiot proof UI". The people I am building this software jokingly feigned offense to the term, but I can see where this term would actually make people upset.

What's a nicer way to say this?

Answer 1

If you are including "Idiot proof UI" as a schedule item then you are just trying to add quality afterwards to your software. Any well designed system will validate its inputs and give clear guidance to users as a matter of course, it's not something that gets put on the schedule as a discrete item (which is then subject to removal when the inevitable crunch hits).

Alternatively, if it has to be a discrete item (I know how some organizations think about scheduling), "Idiot proof UI" should be changed to "Input Validation Library" and moved to the front of the schedule.

Answer 2

User input validation I'd have thought would be a professional term. I don't see anything wrong with idiot proofing if used in internal documents though.

Answer 3

Hardening is a good word. If anybody asks, tell them the first pass on software is usually written for ideal scenarios, and like steel tools, software needs to be "hardened" toward rough day-to-day usage by real customers.

Robustification is another good word for this - you're making the code robust toward the kinds of challenges real customers will throw at it.

Both words sound cool and industrial, don't blame the users or the programmers, and get the point across.

---

BTW, here's Metrowerks' old mascot Arnold, the guy who used to help us Mac programmers harden and robustify our code with a heat treat furnace, a forge, and an anvil and small sledge hammer:

Answer 4

Defensive Programming

Is what I was taught. Back when we had to whittle our own bits out of wood.

If you want to be PC, call it "anticipatory" programming.

Answer 5

When I was learning, we called it bullet proofing.

Most of the other euphemisms I've read apply too, though.

Answer 6

How about "Fault tolerant" system or UI?

Answer 7

"Idiot proofing" should consist of both

• designing the UI so that it is user friendly and leads the user to enter data in the way that the programmers expect, and

• testing the UI to determine whether the interface can be broken by entering unexpected data values.

Both steps might reasonably appear on development schedule where the design is vetted by a user experience expert and where the delivered code is vetted by a tester to ensure that invalid data is handled correctly (for whatever "correctly" means to your application).

Answer 8

Idiot-proofing involves a lot more than simple input validation. I wouldn't even include such a thing in its definition.

Input validation is a process where you sanitize and validate user data to both eliminate illegal/nonsensical values. This should always be done with any information coming from outside of your program so as to eliminate the obvious as well as protecting yourself from attacks (e.g. sql injection attacks).

I would consider idiot-proofing to be a set of logic to keep the user from accidentally causing great damage to him/herself through otherwise legal means.

For instance, making rm reject the command rm -rf / and close variants has nothing to do with validation or correctness. It's a perfectly valid command. Unfortunately, it's a command which could and can wipe out all of your data from all of your disks in Unix/Linux. Idiot proofing this would reject this command and would suggest rm -rf --i-really-mean-this /, or if in interactive mode, have the user type in an affirmative response after a warning.

Anything which is destructive to the system should be idiot-proofed. Anything which could cause potential embarrassment might also be a candidate (e.g. "are you sure you want to send this email without an attachment even though you mentioned one in your text?", and "are you sure you want to send this email to the entire company?")

Idiot-proofing is a collaboration between QA (trying to be the best idiot) and Development (trying to anticipate all of these scenarios and designing around them).

As for a more friendly synonym, may I suggest "destructive code-path analysis" or "enable user feedback for critical operations". Whatever you may call it, you should really start it as early in the design process as possible.

Answer 9

"Sanity Checking" tends to work pretty well quite often...

Answer 10

Call it "adding Poka-yokes to the UI". http://en.wikipedia.org/wiki/Poka_yoke

Answer 11

"Error handling" or "input validation" would be other terms I'd use for what you describe. Bulletproof would be another term that I could see being used in some circles as the idea here is to make the software robust enough to handle almost anything. Rock solid would be another slang phrase I could imagine someone wanting to use here too.

Answer 12

"Worst case scenario proofing". Because, as developers, we all know that if it can be done, then it will be done. So you just have to be prepared to handle that worst case scenario situation with your software.

Security measures aren't just a way to protect users against outside cyber invasions, but also against themselves. We live in an imperfect world with imperfect users.

Answer 13

Gold-plating is the polite (and very positive sounding) term I use when talking about improving end-user interface experience in any way (GUI or other).

Idiot-proofing, as you say, is the largest part of that process, along with design or workflow improvements (think end-user feedback acknowledgment).

The idea here is that you can use that term freely in the work environment and its seen as a valuable process (once completed) by both management and users, even though it may take some time (and thus generally costs some money).

many other terms related to this (often end-of-cycle) process make it sound like this process:

• implies users (often management ;-) are dumb
• is hard to achieve
• has little net worth

By associating gold with the process (metal usually equated to "worth" rather than "cost"), I've seen the process become changed from expense to investment in some managers mindsets.

Its like openly stating that until this is done, that clunky piece of steel isn't jewelry yet. But once its plated... then its valuable.

Answer 14

Most often using in relation to manufacturing processes but I think a really good fit is Poka-Yoke:

"[poka yo-ke] is a Japanese term that means "fail-safing" or "mistake-proofing"

It was originally described as baka-yoke, but as this means "fool-proofing" (or "idiot-proofing") the name was changed to the milder poka-yoke.

More broadly, the term can refer to any behavior-shaping constraint designed into a product to prevent incorrect operation by the user."

Answer 15

A common term in bigger shops is also Quality Assurance (QA).

Its a general, vague on purpose term which you can mold to your own specific meaning within your release cycle.

Answer 16

We call it Human Proofing. We are all idiots.