Defensive Programming

I need to improve my defensive programming. This kind (the third bullet from Wikipedia): “Making the software behave in a predictable manner despite unexpected inputs or user actions.”

I use the tools that are available to me. I make fields that should receive numbers into number fields. I make required fields, well, required. I use field validation and translation. I don’t allow pasting or deleting in applications where users shouldn’t be pasting or deleting. I use drop down lists where possible and don’t “Allow Values Not in List” wherever possible. I use Julian Robichaux’s awesome OpenLog for error handling. The list goes on.

I test the applications. I test them myself first. I test them with actual users. I BEG them to try and do what they would normally do. I ask them (dare them) to try and break the application during testing.

And STILL those pesky users find ways to break the application *after* the final release.

I swear the UI could include a blank screen with a giant button in the middle that says “Click Here” and users will still say it doesn’t work because they clicked on the menu, and tried to select “Create” and do five other things besides hitting the giant button. . Maybe it’s my fault. I told this to Bob Balaban and he said the button should say “Click Here TO DO EVERYTHING”. :)

So my goal is to improve the ways in which I can program defensively. Yes, the onus is on me. I have to get better for a couple of reasons. 1) It is actually my job. 2) It makes my life easier (less complaints, less training, less calls).

On the other hand, complaining about users is a lot of fun. ;)