randomseeds logo
Back to Blog
Defensive Programming for Better UX
March 15, 2024

Defensive Programming for Better UX

There are plenty of great articles on defensive programming, and I'm a strong believer in it. While the topic can dive deep into security, database abstraction, and philosophical debates like whitelist vs. blacklist, I see it as a practical balance between writing solid code and shipping efficiently.

In my current role, I help teams strike that balance while advocating for UX as part of the development mindset. This post stems from a debate with developers over a defect related to missing character limits in a text input. Their defense? "It wasn't in the acceptance criteria."

Beyond Acceptance Criteria

Acceptance criteria define the new functionality for a user story, not every fundamental best practice. Inputs should always be defensively validated for things like length, special characters, and required fields unless there's a good reason not to.

Skipping that work guarantees future defects, QA churn, and even security risks. Of course there should be a character limit. Of course we should escape or restrict special characters. Defensive programming helps avoid pain later.

Leverage Component Libraries

Ideally, your component library or "kitchen sink" should offer accessible, 508-compliant UI components with basic validation baked in. No major framework handles all of this out of the box, but with a solid design system, your team shouldn't reinvent validations for every feature.

If you're building raw UIs from scratch and tacking on accessibility and validation after, you're doing extra work—and risking consistency.

The Hidden Costs of Skipping It

Think about the time lost fixing bugs that could've been prevented.

Think about the QA cycles burned on rework.

Worse, think about the real damage caused by validation bugs in production.

All of that goes away when thoughtful defaults are built in from the start.

The UX Payoff

From a user experience perspective, consistent validation creates trust and ease of use. When inputs behave the same across screens, users learn your system faster, feel more in control, and make fewer errors.

Defensive programming isn't just good engineering, it's good UX.