Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?


locked by World Engineer Aug 5 '13 at 0:05

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as off topic by Mark Trapp Aug 28 '11 at 20:01

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

Call it, ID-10T Proofing –  Jarrod Nettles Jul 11 '11 at 20:10
Lol, I realized the 1337 as I googled ID-10T. me fail... –  sooprise Jul 11 '11 at 20:11
This question reminds me of one of my favorite quotes: "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." ~ Rich Cook –  KallDrexx Jul 11 '11 at 20:18
hows about basic engineering? –  jk. Jul 11 '11 at 20:45
"Nothing can be made foolproof, because fools are so damn ingenious." –  M.Sameer Jul 12 '11 at 1:57

16 Answers 16

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.

+1. If you're trying to add any sort of input validation after the fact, you have already pretty much lost. Better to have as a standing point in the spec, "the software must gracefully handle invalid inputs anywhere". Exactly how to "gracefully" handle invalid input depends very much on what the software is doing at that particular point. For very simple UIs (think perhaps an ATM), it might even be possible to make invalid inputs impossible. –  Michael Kjörling Jul 11 '11 at 20:40
+1. Idiot-proofing isn't a task. Idiot-proof is a consequence of good design. –  S.Lott Jul 11 '11 at 20:48
Idiot-proofing is an ongoing process - because the universe keeps manufacturing ever-more-ingenious idiots –  Steven A. Lowe Jul 12 '11 at 2:22

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.

You had me at "user input validation." Idiot proofing is an unprofessional term regardless of where it is used. –  Robert Harvey Jul 11 '11 at 20:17
Whatever you do, don't put it in writing. –  JeffO Jul 11 '11 at 21:27

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:


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.


When I was learning, we called it bullet proofing.

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


How about "Fault tolerant" system or UI?


"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).


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.


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

To me, "sanity checking" means about the same thing as "assert": making sure that internal state is correct. Not really the same thing as external input validation. –  Mason Wheeler Jul 11 '11 at 20:17

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


"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.


"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.


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.


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."


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.


We call it Human Proofing. We are all idiots.


Not the answer you're looking for? Browse other questions tagged or ask your own question.