Defensive Programming for Better UX

There are lots of good articles about defensive programming out there, and I’m a strong believer in it. The topic of the discussion can get nitty-gritty to the depths of security and database abstraction, whitelist over blacklist, and to some extent can go too far. I believe it’s a balance between solid code and effcient development.

From my current position in helping development teams find that balance and bringing UX into the design and development thinking. This is an excerpt from a response/debate I was having with a couple developers who were protesting some defects regarding validating character limits on a specific text input, saying “… but it wasn’t in the acceptance criteria for the user story to do any validation on that input.”

In my mind the acceptance criteria for a user story is specific to the new functionality being developed in that story, and should not have to cover every basic validation other than some specific rules based on the context of the functionality, or things required for this feature.  

It is really in the developer’s best interest to exercise “defensive programming”

and validate any/all inputs for basic things like special characters, reasonable character limits, required fields. To not do so is asking for guaranteed defects and extra work later. Of course there should be a character limit, of course we should limit special characters for any text input as they are problematic unless they are needed for particular reasons.

To go even further, a good UI development setup would be to have a “kitchen sink” or library of vetted 508 compliant UI components with basic validations in place, and a developer uses these to build things. I don’t know of any framework that does all of this out-of-the-box, some get close, but most need some little extra 508 or validation work.

It would be concerning if we are creating bare-bone UI’s and then adding in 508 and certain piece-meal validations for every feature independently.

Think about how much extra work and planning (lack of) that is!

Think about the how much rework we create for later via defects and churn with QA!

Or worse, think about the things we may miss then get caught with serious validation or security issues with defects in production.

How awesome it is to not worry about any of this if they are baked in from the beginning.

Plus from a UX perspective, the validation behaviors and UI interactions overall become more consistent and familiar from page to page, feature to feature.