What is defensive design computing

Defensive design

We all love the possibility of doing something new. Greenfield projects, big rewrites, new framework/libraries, etc. But as scope creeps in, it slowly becomes the New Old Thing again. The cycle repeats.

I pick tools and approaches that fundamentally don’t allow me to make the same old mistakes. It is a form of Defensive design.

Here is a list of stuff that have aided in that journey so far. They are not perfect, there is something to love and hate. I’m not selling unicorns here. But rather the opposite — it’s the limitations that are considered as features.

Protocol buffers

Duh, how is this a defensive design?

Defense: Against fat models

You know, those fat mutatable models with a deep nested structure, having scattered domain logic thrown inside everywhere. This is where I’ve seen the ugly sides of OOP. I had a chance to rewrite certain parts of our application. One way was to start from fresh domain classes that start out slim. But there was no guarantee that someone wouldn’t add a domain logic method in there. All it takes is just one or two methods, and then it becomes the new norm. Everyone follows suit. Mocks for data classes slowly come up because they also happen to contain domain logic. And voila, we have a new old thing again.

Modeling them as protobufs sealed their fate. I could only use them as data holders now, and they just cannot become those scattered domain logic again. Immutability of these objects is a further added plus. There is no more possibility of adding custom domain methods to values, and then stubbing/mocking random stuff for testing.

Many languages offer similar defense using data/case classes (as in Python, Scala, Kotlin, etc). But they don’t restrict from adding methods or domain logic to it. This is where I get stronger defense from the data-only, sealed and heavily introspectable nature of protobufs. So much of the old architectural style was killed by using protobuf, that I started using them as a de-facto replacement for data classes everywhere — Messages in background queues, NoSQL documents, even POJOs.

Defense: Against half-baked contract management

XSD and JSON-Schema also try to define schemas for objects. e.g. Javascript is fundamentally untyped. This led JSON-Schema to describe types as a validation. Property “x” should be of type “number”. The natural extension of that was, the “number” should be between “0 to 10”, and so on. This took JSON-Schema from schema definition to data validation which is a totally different problem domain! Protobuf’s limitation feature is that it will let us do pure schema management without validation.

Data validation has a (1) constraint definition problem that needs a turing-complete language — dependent validations such as two dates should not repeated, two time windows should not overlap, a.b.c should be present if x.y.z is true and so on. Trying to represent these as “configuration” is wrong. It’s code. It has a (2) data explosion problem — try validating if a given day is a holiday or a weekend, or if a zipcode is valid (not just the length, but if the actual value is semantically correct). To do it right, you need to add all the known zipcodes/holidays in the country to the schema file. Lastly, it’s also a (3) network/IO problem: any place where a 3rd party system has to be called to complete the validation, e.g. if a given entity ID or phone number exists, if an association is present, etc.

JSON-Schema and XSD try to validate stuff, but they cannot cover it fully because it has computational/data/network complexity that just cannot be described as metadata. And this ends up in half-baked contracts. You assume that if your payload passes the schema, it’s a valid payload. It could be anything but!

While trying hard to further solve validation, some fundamental stuff is overlooked. Anyone know what’s the scale/precision of a number in JSON? How to properly represent a Bigdecimal or Date or DateTime or UUID? How to do first-class artifact management? Namespacing, referencing, embedding from different runtime schemas, backwards compatibility, preserving unknown fields, …?

Using Protocol buffers limited me to just use it for defining a schema. No half-baked validation logic. No serialization/deserialization issues. Guaranteed interoperable data types. It does one thing and does it well. These schemas are then easily shared everywhere irrespective of protocol or stack.

Golang

Defense: Against over-engineering

There is much to love/hate about Golang, which we won’t get into here. Let’s just look at the defensive capabilities.

You cannot run into an Over-engineered Abstract Universe with fancy pants class names and onion skin layers that keep peeling and peeling. You won’t find 16 design patterns for every 32 lines. You won’t find enterprise fizzbuzz.

Golang just doesn’t have a way to let your software become a legacy monster. People will have to work really hard to conceal code behind layers. If anything, it’s the opposite —code will be thrown right on your face.

It’s a very useful tool when rewriting systems while being safe that the same old legacy cruft cannot hit you back. Of course, you’ll definitely have withdrawal symptoms for a long time. When the brain and workplace is tuned to be rewarded for doing things “the complicated way”, there will be a heavy dopamine hit when writing the first few for loops. I wish more languages took the Golang approach and started adding defensive limitations in new versions, rather than bloated features.

Defense: Towards programming correctnesss

Rust is a specialized form of defense for programming correctness. To be frank, I have not dabbled in Rust as much to be able to write about it. But a huge swath of runtime errors are caught during compile time, and your program almost always runs without issues in production if it compiles, is one of the most sophisticated forms of defense that I’ve ever come across.

Rust looks quite defenseless against over-engineering and its easy to get lost in long type signatures and possibility of abstract universes. But the community seems to be doing a great job so far, and the language is getting better and better with each release.

Message queues

Defense: Towards resilient tasks

We’re not going to talk about Event sourcing, Reactive programming and Stream processing. Let’s go straight to the core defense: The fact that you can do things with resilience built-in.

I’ve seen distributed cron jobs being processed resiliently, simply by having a domain-logic free “cron-as-a-service” where consumers create a schedule, and it merely publishes each cron trigger as a message on a queue. I’ve scaled up many instances of consumers with a guarantee of the cron message being processed by only one of them at a time, with retries in case of failures.

I have had huge success with converting all background tasks to be queue-driven, running lightweight APIs that receive requests and just self-post a message to themselves to reliably process it. I’ve had all RESTful POST requests in a previous application that internally sends a message to itself, and responds with 202 Accepted. I’ve written some GitHub apps and integrations where whenever I need to do anything using the GitHub API, I make the application send a message to itself. “Please label this issue as X”. And it will keep retrying until that happens. The fact that you can also control concurrency and guarantee to be within rate limits by just increasing/decreasing the number of workers to fit. And went on to having critical operations as a single “Job” resource — just send all operations to POST /jobs, with every job having full fledged status monitoring and ownership, all modeled just as a message.

Overall, plain vanilla Message queues are a powerful reliability defense in general, without even getting into Event sourcing and Reactive programming.

Ephemeral Infrastructure

Defense: Against snowflake infrastructure

If you are stuck in a snowflake infrastructure company, all you need to do is just “ ask for autoscaling”. A huge correction will automatically follow.

With elasticity, new instances can be booted up anytime, and the booted resource has to auto-provision itself within few minutes. This automatically pushes up the bar up for configuration management and infrastructure automation. Similarly, what goes up has to come down. This means, you cannot do old style “stop and drain traffic manually” with your operations team anymore. You have no choice but to implement graceful shutdown, connection draining and proper health checks.

Ephemeral infrastructure is a broad term. Immutable Infrastructure (disk images or containers) is just one part of it, and it takes it one step further. You’ll have to end up implementing even more practices like 12factor, rolling updates and removing silos.

By choosing ephemeral infrastructure, the engineering teams just don’t have an option to make the same old snowflake mistakes.

Chaos Engineering

Defense: Towards resilient infrastructure

At my present company, we constantly kill pods/nodes and trigger re-provisioning of resources. We use a customized form of Chaos engineering purely targeting kubernetes.

Having automated tools that trigger various types of infrastructure, network and application errors and failures is an effective early defense, even before deploying your first service.

Service meshes

Defense: Towards fault tolerant integrations

The world is a distributed system. Today it’s hard to write an application that’s completely standalone without leveraging a bunch of external APIs. Cloud resources, backing services, third party authentication, notifications and much more.

So far, I’ve gotten into a standard practice of enveloping every 3rd party call that goes out of my application with the following, irrespective whether it’s needed or it’s my own service on the other side or a third party: timeout, retry with backoff, circuit breaker, record metrics per status, print a log with metadata, add my own metadata (client, session, request identifiers, date/time, version), etc. Because you know Murphy’s law: If anything can go wrong, it will.

But the days of requiring a library to do all these for each call are slowly winding down, and these tasks are also becoming plug-and-play services in the form of sidecars or reverse proxies that you can pipe requests through.

In the context of defensive design, I’m slowly exploring service meshes such as istio/envoy, linkerd, kong, etc, using them for resilience and keeping the service discovery and configuration management parts aside.

Function-as-a-Service

Defense: Against bloated architecture

Warning: There are library/dependency management, business continuity (will my business continue to work in reduced mode after reaching artificial quotas/limits, or do I just shut store for rest of the month?), latency, caching, state management, vendor lock-in, lack of open standards, metrics, orchestration, standardized config management, unified communication gateways and a bunch of other open concerns with FaaS right now. This is an experimental item in this list.

The fact that I don’t have to worry about infrastructure at all is a huge defense. No 12factor or health checks needed. No complex infrastructure orchestration. Every service can evolve at the same time to major languages and environments, without needing to be rebuilt. This gives a different level of continuous delivery for operational teams.

You don’t have to wade through standard boilerplate, go through gazillion ways to configure and bootstrap things, and do an expensive redeploy to make small changes to domain logic. One function can do only one thing, which makes internal contributions and cross-team collaboration easier.

I’m still eagerly waiting for the next few years to see how/if this field evolves holistically. After two years, if we’re still only talking about idle billing, then so much for defense.

Conclusion

Those are some of my favorite Defensive design tools/approaches. I’d love to hear what are yours.

Defensive Programming Techniques Explained with Examples

Table of Contents

What is Defensive Programming

Defensive Programming is the development of computer software putting in mind all the unforeseen circumstances that could raise problematic issues. That allows the software to behave correctly despite the input provided. This development technique is mainly utilized when coding software that should be highly available, safe, and secure from malicious attempts. Defensive Programming techniques help improve Software and Source code through:

Categories of Defensive Programming

There are two main categories of defensive programming:

Secure Programming

Secure programming is a category of Defensive programming that emphasizes the development of highly secure programs. In such a case, the availability and safety of the software are not a priority. The software can fail in certain ways as long as it is secure from any malicious exploitation attempts. Like any defensive program, minimizing the number of bugs and any arising problems should be considered, but reducing the likelihood of the program failing is not a major concern compared to reducing the attack surface. The developer should have a mindset that the program can be misused or tricked into revealing bugs or security flaws that can be exploited.

Let’s take a look at the piece of code below:

In the above program, the developers set the user input to 1000 characters. If it was a username field, they did not imagine a user can enter more than 1000 characters. However, this is a bug that can be exploited using buffer overflow exploitation attacks. A reliable solution to this would be to use the code below:

Offensive Programming

Normally, defensive programming emphasizes total Fault Tolerance. A situation where the software will continue working normally in the event of failure or an error arising within its components. Offensive Programming, however, takes a different approach on that. According to offensive programming, the errors that should be handled defensively should come from outside the applications, such as user input. Errors arising from within the program itself should be exempted from total Fault Tolerance. There are two methodologies applied in Offensive Programming:

Let’s take a look at the two methodologies using code samples:

Trusting internal data validity

Overly Defensive Programming

Offensive Programming Solution of the above code.

Trusting Software Components

Overly Defensive Programming

Offensive Programming Solution of the above code.

Defensive Programming Techniques

Up to this point, I believe you now have a good understanding of defensive programming. Let’s dive in and look at three techniques you can use to write defensive source code.

Guard Clauses — Checking Pre-Conditions

The use of pre-conditions is the most common and widely utilized technique in Defensive Programming. These one-liner statements are used to validate your input, ensuring that the methods and functions continue to execute only when the correct input is provided. Let’s take a look at the example below:

In the above code, we check whether we are provided with a non-null or an empty value. This check is important in situations where proceeding with non-null or empty values could result in incorrect output.

When the method takes multiple arguments or one argument calls for multiple guard clauses, we will need to refactor to another guard clause approach. Instead of writing multiple checks, we can have one object that holds all our properties and the IsValid() method. Take a look at the piece of code below.

In the above code, the IsValid() function validates if every property meets the required requirements.

Assertions

Assertions are another important concept in Defensive Programing. They are used to confirm that the assumption made on the program’s execution flow is correct by adding assert statements validated at runtime. In real-life software development, assertions come in handy when working with third-party modules and libraries you import into your project. You cannot fully trust these libraries, and it’s important to check and confirm whether the output they give falls within the expected range.

Let’s take a look at the example below:

In the above code, we are anticipating any errors that may arise. After invoking the database.save() method, we have used a if statement to assert what happened and act accordingly.

Nulls

One of the many causes of bugs in Object Oriented Programing is Nulls. That is mainly due to the inability to distinguish between nullable and non-nullable reference types. To avoid these null bugs, most developers write multiple null checks in almost every method and constructor (Defensive Coding). See the sample code below.

Even though these checks can be essential, having so many of them can cause errors to slip through the programmer’s eyes. To avoid using these many validations, there are various methods that you can apply.

One, you can decide to use a language that does not support any nulls at all. They include Haskell, Ruby, Smalltalk, and many more. Therefore, the problem of null references doesn’t arise at all. Another related solution would be to use a language that does have null but supports null tracking to avoid any null references. One of such languages is Spec#.

If you are developing software using popular OOP languages like Java, you can define a special Struct that distinguishes nullable and non-nullable reference types. Additionally, you can also import the Fody.NullGuard library, which automatically checks for all input parameters that weren’t marked with the struct.

Conclusion

Defensive programming can be tough to write source code, but it results in high-quality foolproof code. Without Defensive programming, your code will still run normally. However, it can easily break or give incorrect output depending on the condition or user input.

Related Posts

Didn’t find what you were looking for? Perform a quick search across GoLinuxCloud

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

For any other feedbacks or questions you can either use the comments section or contact me form.

Thank You for your support!!

An Overview of Defensive Design

All over the Web, at any given moment, something is going wrong. It’s not an issue we take lightly, yet it still occurs! No I’m not here to talk about our over dependence upon third party tools or IE6 (specifically), I’m here to talk about site glitches, and how to avoid them.

Occasionally these bugs are small visible glitches, occurring as a result of mismanaged code; or in many other cases, Internet Explorer. Other-times they result from the natural aging process of a site and its ever growing collection of pages. In this article we’re going to explore the world of site-based hiccups and how we can ensure that our sites don’t become associated with the fail whale!

Introduction

In recent years, we have placed a great deal of effort as an industry, following the topics that get lots of attention. Fashionable subjects include responsive design, user-experience, psychology and the buzzword infused languages we use daily like HTML5 and CSS3. Yet while this is going on, one of the fundamental parts of site ownership, the maintenance process, rarely gets much attention. It’s central to usability, it’s critical to design, and without it, sites would be a mess. Yet when it comes to reducing error ratios, many sites (even smaller, easier to maintain ones) fall quite short of the mark.

What is Defensive Design?

Combatting these evil forces, be they bugs or reoccurring errors, is an on-going battle that cannot be won overnight. In much the same way as Ash from the Evil Dead franchise, we endlessly charge into action with our trusty code chainsaws and bug bashing boom-sticks to save the day. The process of cleaning sites and ensuring that they’re as user-friendly as possible is referred to as defensive design.

Essentially, our goal is to support our sites in times of trouble, purge those errors relating to lost files or the unavailability of resources, ensure that our layouts do what they’re supposed to, help the user complete actions, and avoid throwing visitors into a bottleneck of confusion. Defensive design is as much about reducing user confusion as it is about iterating bugs out of the system.

Why does this Matter?

Given that most of the Internet’s users are mortals, unwise to the issues that geek superheroes are able to traverse with ease, we need to take care to help avoid causing them undue stress. Visitors are temperamental creatures that could ditch your site in search of an easier to browse option upon suffering one too many errors. If you can provide a site that loads quickly, works effectively, handles errors (as best as can be expected) and avoids alienating the user with roadblocks, you increase your chances of success. After all, a happy and contented user is more likely to remain a customer!

Legacy of the Lost

If there’s one thing I can’t stand, it’s obtrusiveness online. When things go seriously wrong, it can put you off visiting the site in the first place; or if you frequent the domain regularly, bothering to return later on. In this modern age of 24/7 global Internet access; issues like downtime, missing resources or pushy sites that complain because the user doesn’t have JavaScript enabled or Flash available on their iOS device shouldn’t still be happening. So let’s see how you can reduce these issues.

Server Outages

At some point or another, we’ve all encountered server related mishaps. Whether it’s down to DNS issues, overspending your allotted bandwidth, downtime for maintenance, or a simple malfunction that’s resulted in the Twitter fail whale. It’s the kind of error we cannot afford to ignore because unless we do something, the site becomes unavailable to everyone, s which is quite a scary thought!

Consider the following:

Missing Resources

The dreaded 404 error has become a part of our culture, with pretty much every site suffering one at some stage or another, and every user having met one during their time online. This could include a link to an image that’s disappeared since redesigning, or a page that no longer exists in the archives. Ensure that you seek and destroy these broken beasts and fix regular user invoked errors.

Consider the following:

Unsupported Technology

While languages like HTML have provided an open, mostly compatible way to ensure that our work functions for everyone, other technologies have not been so lucky. In some cases, the issue is down to the adoption levels of a proprietary system, in others; it’s just down to the fact that the thing we rely upon can be disabled. In all cases, we cannot afford to ignore the problems this can cause.

Consider the following:

Sustainable Layouts

It seems that many Web designers are secretly cheating on their spouses, huddled in front of their computer monitors giving doe eyed looks at responsive Web designs and thinking about how much they’re in pixel love. In this age of design lust, it only makes sense to cover some of the issues we need to defend our visuals against.

Responsive Flexibility

Defensive design isn’t just about the obvious bugs that annoy our users to the point of drawing their computers a nice warm bath. It requires us to think outside of the box and try to avoid the kinds of common complaints, which can break a layout or render a design unusable. There are many general issues relating to the aesthetic of a page, which can be resolved with just a little common sense.

Consider the following:

Cross-Browser Support

Web browsers have become the bane of many designers’ lives. We spend days putting some code into a beautiful format, only to on occasion spend additional hours, frustratingly pleading with the browser that won’t do as it’s told. If you’re the designer, you might want to say “to hell with it”, but if you’re a user and you follow the same philosophy, that’s one visitor you’ve lost to a visible glitch.

Consider the following:

Accessibility Needs

While user-experience design seems to be hogging most of the glory in respect to getting coders and designers alike excited about how to keep the customers happy, accessibility in many cases often gets swept under the rug. It’s a scary statistic that the majority of sites today are still inaccessible and this has to change. Especially as such issues could block an entire demographic from your site.

Consider the following:

Reducing Input Errors

While the aesthetics of our site are important, it goes without saying that issues relating to form input and page interaction are often the most damaging to the user. We can get away with a site not looking its best in IE6, but if a visitor can’t even utilize a contact form without errors occurring, you may as well turn yourself into the usability police to be arrest without bail. Dealing with input issues may seem scary, but as you’ll now discover, it’s really just about thinking in terms of practicality.

Intelligent Feedback

Computers aren’t very smart, let’s be honest. In terms of Web development, the closest we can get to achieving intelligent feedback is to examine what the user is doing, and try to make a prediction based on how others have used the service. The principle behind this technique is simple: if you can identify where errors commonly occur, you can assist the user by forcing them to take extra care.

Consider the following:

On-Page Assistants

While providing users with some feedback during the input process is helpful, it also makes sense to provide additional support to users to help them understand what is required of them before they commence data entry. While intelligent feedback focuses on spotting and resolving errors as and when they occur, assistants try to explain the process better, to avoid it occurring in the first place.

Consider the following:

Delayed Correction

As we’ve stated before, errors happen and no matter how much assistance you give a user, they will always find a way to either ignore your helpful hints or cause a glitch that puts them in a pickle of a situation. As such, in addition to the pre and post data entry process, it’s important that visitors can amend their details, undo mistaken actions and be empowered to “help themselves” when possible.

Consider the following:

The Neverending Story

If you talk to a software developer, one thing they’ll inevitably tell you is that no product, no matter how simple is ever 100% bug free. The second someone makes that claim, a user somehow manages to break the application, even if it is as simple as «hello world». Inevitably, you cannot defend your site against the on-going issues of errors in one single swoop. As your site evolves, you will need to keep revisiting and repairing as you work to ensure that what was here today isn’t broke tomorrow!

The truth is, we live in a digital universe that’s infested with link rot, missing content, broken and obsolete code, and the situation only seems to be getting worse. While there isn’t much we can do about the sites that time forgot, you could and should improve the situation for your users. Take the time to spot check your site, look back through those archives, keep cross-browser testing and never take anything for granted, especially as your users will critique you for serious failings.

In terms of customer service, you can be forgiven for having errors in your products as regardless of how hard you try, things can go wrong. But don’t take that as a sign to give up and let the bugs keep coming, as it’s how you deal with them that matters the most. If you work quickly to resolve an issue, visitors will likely feel better about you and your site; as you’re rewarding their feedback with fixes rather than punishing them with continued errors. But if you don’t make your site defensive, you might silently lose visitors, and that’s not something any of us should be willing to settle for.

Getting Started With Defensive Web Design

About The Author

Ian Lurie is an internet marketer and President of Portent, the agency he founded in 1995. He writes about marketing, communications and search on his blog, … More about Ian ↬

Email Newsletter

Nothing ruins a great website UI like people using it. At least, it often feels that way. You put in days or weeks building the interface, only to find that a vast majority of visitors abandon it partway through the process that it supports.

Most of the time, visitors leave because they’ve hit a roadblock: a problem that lets them go no further. They typed their credit card number wrong or clicked the wrong link or mistyped a URL. And it’s not their fault..

Further Reading on SmashingMag:

A good design assumes that people make mistakes. A bad one leaves visitors stuck at a dead end because they mistyped one character. The best professionals account for this with smart, defensive design strategies (also known as contingency design).

Meet Smashing Online Workshops on front-end & UX, with practical takeaways, live sessions, video recordings and a friendly Q&A. On design systems, UX, web performance and CSS/JS. With Brad Frost, Stephanie Troeth and so many others.

Defensive Design Means…

I’m a simple guy. In the book Defensive Design for the Web, 37Signals defines defensive design as such: “Design for when things go wrong.”

Gets right to the point, doesn’t it? Defensive design anticipates both user and website error. Then, it tries to prevent those errors and provide help to get the user back on track. Defensive design for the Web usually focuses on the most common points of failure: forms, search, the address bar and server problems.

Defensive Design: Business Sense

If you want to grow your online business or just improve your blog, defensive design is one of the easiest upgrades — instead of trying to build audience, defensive design helps you better serve the audience you’ve got. The latter is far, far easier than the former.

Self-explanatory. Image by What consumes me

Think about it: You can work on marketing, search engine optimization, community-building, display ads and content strategy, and attract 1,000 new visitors. If 5% of visitors to your online store make a purchase, then those 1,000 new visitors mean 50 new orders. Or, you can practice defensive design. That might increase your current conversion rate from 3% to 3.5%, adding 50 new orders.

The best way to learn defensive design? By example. Here’s a quick overview of best practices, plus some tips for doing it yourself.

Inline And Contextual Help

The best contingency design prevents errors from occurring. Sometimes a simple tip or explanation can prevent error and visitor frustration. Instead of making customers trek to a separate help area, try to assist them with tips and instructions inline or in context.

Inline help offers pointers on specific items on the page. 37Signals provides inline help throughout its applications. For example, I can find out exactly what the 30-day trial of BaseCamp entails without leaving the page:

Inline help on 37Signals clarifies the conditions of the free trial.

The inline help box appears the moment I roll over “30-day free trial.” It’s easy to read, well positioned and clearly related to the free trial. And the language is crystal clear. This is important. Defensive design is as much about the message as it is about the circumstances that call for it.

Contextual help provides guidance relevant to the current page or process. Hence, “contextual.” Unlike inline help, contextual help usually relates to the entire page, and it can appear without a click or rollover.

WordPress offers contextual help in the administration area of the application. The “Get help with dashboard” message appears the first time you open the dashboard. The message might be a bit too lengthy, but it’s helpful and it is right for the given context. Note the simple language, plus the option to dig deeper by going to the full documentation or support forum:

WordPress contextual help alerts me to helpful instructions.

HootSuite explains every feature of its application and service packages with simple inline help boxes. The boxes answer basic questions at a glance, without pulling users away from the all-important sign-up page:

HootSuite uses inline help to explain individual features.

These websites all anticipate that users might miss certain features and requirements. And then they present those features with clear direction, in context. Make no assumptions! A field, button or feature that makes total sense to you may be nonsense to the typical visitor. Provide help.

Slow Connections

Another, subtler form of defensive design accounts for slow Web connections. Downloads can slow to a crawl on mobile connections. When that happens, visitors may be forced to find their way through your website without images or Flash elements to guide their way.

37Signals makes sure that you can read its entire content, including interactive elements, without images. It does this by relying more on CSS and text than on images. Even if the background and images don’t load, critical navigation, calls to action and rollover elements will still work:

Even without images, users can use the 37Signals’ website.

A List Apart looks a bit minimal without images, but everything from the articles to the navigation remains in place. Users can easily find and read the articles they want:

The layout of A List Apart is preserved even without images.

CNN’s home page remains intact without images. Visitors can see all links, search tools, navigation and content in exactly the same position as if images were displayed:

CNN’s website remains 90% intact and navigable without images.

Some designers still want 100% control over type and layout, and they want the freedom to use images, Flash and other slow-loading elements to achieve it. But more and more users are accessing the Web on wireless connections, which are getting faster but are still unreliable. Plan ahead and have a website that still works when bandwidth shrinks.

On-Site Search

On-site search is wonderful, if visitors can actually find what they’re looking for. If your website contains a lot of often misspelled words for products, concepts or services, then your search tool may be an exercise in tooth-gnashing frustration. Anticipate misspellings and typos and turn on-site search into an asset.

Amazon’s on-site search tool automatically recommends close matches. It presents the same kind of “Did you mean?” message that Google does, plus it displays results for the correct spelling of the query:

Amazon modifies search results to show products that match correct spellings.

Like the others, CNN provides closest-match spelling correction. Then it provides two other sets of options: top stories for the closest match and top general searches on the website for that week. The correction and variety of results get visitors back on track so that they don’t have to perform a second search.

CNN returns the closest match of spelling, plus top stories.

These examples anticipate typographical and spelling errors. Sometimes, though, a visitor submits an unusual query: for example, “java” instead of “coffee,” or “band” instead of “ring.”

Zappos provides a graceful solution by making its search results transparent. The website examines your query and shows categories and concepts to which your search maps. Plus, the user has the option to remove any of the categories from the search result:

Zappos clarifies how it delivers results and lets you correct them.

So, if I submit the wrong query, Zappos might show me the wrong results, but it also shows me why the results are wrong and helps me figure out a better search.

If you’re just running a small website in your spare time, these automated search suggestions and mapping tools may seem out of reach. But they’re not. Tools like Google’s Custom Search give you them from the start. And if you’re feeling nerdy, solutions like Lucene come with entire libraries that do “Did you mean?” matching and let you customize matches. Or you can write your own script to identify common misspellings and handle them exactly the way you want. How fancy you get is up to you.

Form Validation And Error Handling

Forms are the number one cause of customer’s hate. Filling out a form requires a lot of work — it forces you to do the hardest combination of clicking-typing-clicking, and often involves digging through your wallet for credit cards and other information. A typo, missing field or incorrectly formatted phone number can force a visitor into a loop of retype-submit-retype, fixing their errors one at a time. Smart defensive design starts with clear direction (see the section on “Inline Help” above).

But mistakes happen. So, defensive form design does the following:

Wufoo highlights errors, explains exactly what the user did wrong and preserves the data across refreshes, which makes corrections easy. The only problem with the design is that the message “There was a problem creating your account” doesn’t tell me anything useful. A more descriptive message would be better.

Wufoo highlights what you did wrong, but a clearer message would help a lot.

FreshBooks keeps it nice and simple. Even better, it doesn’t make users feel like they’ve failed a test:

The form message on FreshBooks is simple and friendly.

Complex and simple form layouts can provide equally great feedback and help users get back on track, as the following screenshots of SEOmoz and MailChimp show.

SEOmoz’s form tells you when two fields don’t match.

MailChimp uses JavaScript to validate inline as you type, so you can correct mistakes before submitting the form:

MailChimp validates before you click “Submit,” saving you even more time.

Another interesting technique for defensive design in Web forms is presented on Mailchimp when a user tries to delete his/her subscriber list from their account. The tool requires a user to manually type “DELETE” to confirm the action. A nice example of making sure that the list will not be deleted by accident. The technique might look a bit annoying at first glance, but it clearly minimizes the error rate for users who delete sensitive data by mistake.

“Type ‘DELETE’” pattern on Mailchimp. It will save users some headache.

Great contingency design never gets in the way. In all of these examples, each error is highlighted. Also, the description of the error is positioned near the relevant field, so it’s easy for visitors to find and fix the mistake. This keeps the form compact, maintains eye flow and lets the visitor continue with their task uninterrupted.

“Page Not Found” Errors

On the internet, broken links are abundant. A webmaster may have moved a page or mistyped the URL in a link, or a visitor may have left out a forward slash from an address. Whatever the cause, the last thing the user wants to see is this vaguely hostile message:

A bad 404 page. Somewhat upsetting, isn’t it?

Great websites customize their “Page not found” area (also called a 404 page), by providing options, explaining what happened or even injecting a little humor into what can otherwise be a frustrating experience.

ThinkGeek includes full navigation on its 404 page. It also provides a search form, so if I know what I’m looking for but not the URL, I can submit a query to track it down. (Assuming the Jedi mind trick doesn’t work…)

ThinkGeek tries Jedi mind tricks but doesn’t rely solely on them.

Climate Wisconsin keeps it simple, with two options on their 404 page. It’s easy to quickly digest, and the visitor can immediately decide their next action:

Climate Wisconsin’s 404 error page is simple and to the point. A search functionality could be a useful helper for users, though.

You don’t have to make the 404 page a work of art. Just make sure that if a detour is required, you do the following:

Server Errors

Sometimes things just go kerploiee. That’s a technical term for when your server, tired of its humdrum day-to-day existence, stops delivering pages, flips over on its back, lets out a horrid gurgling sound, and utterly fails to deliver content, data, information or anything else.

Normally, this will give the user a message like this:

A standard 500 server error. Scary at the best of times.

Imagine you’re the visitor. What does this page tell you? That the apocalypse is at hand? Or that you have to find something called a “server error log”? Which pretty much means the apocalypse is at hand. Either way, you’re going to cross this website off your list.

Great contingency design accounts for everything, including servers going kaput.

Here’s the page on Carsonified. It explains what happened and lets you send a message to its developer, Elliott Kember:

Carsonified leaves nothing to chance, and it says a few words about the person who may have caused the error.

The Food Network isn’t as entertaining, but it certainly makes sure that users know it’s still in business. And like any good 404 page, it gives users a few ways to get back on track:

Even if the Web server dies, a user knows that the Food Network is still around.

Brushfire Digital explains the error, provides navigation and contact information and, again, makes sure you know it’s still there:

Brushfire makes sure you know it’s not you — it’s them.

Again, you don’t need to create a work of art. Just make sure visitors know that the error probably isn’t their fault and that you’re taking care of it.

Detect Holes In Your Defenses

Some defensive design issues are easy to spot: bad forms, error messages and inline help are obvious. But you can spot subtler issues and their solutions using some basic Web analytics.

The Checkout Funnel

You can grow sales in a hurry by getting more of your existing audience to purchase. That’s far easier than getting more visitors. So look at your checkout funnel to see if there are any places where many new customers abandon their shopping cart. In this example, over 70% of visitors who place items in their cart abandon the checkout process. The overall sales conversion rate is 1.7%:

A broken checkout funnel. It’s losing 70% of potential customers at the first step.

This is a true story, by the way. The problem was very clear: customers abandon on the initial checkout page. We thought the cause might be the page’s layout. It gave visitors a strong impression they’d have to register in order to check out. So, we changed the page, adding inline help and a modified layout to make the guest checkout option clearer. Cart abandonment on the first page dropped dramatically, and overall sales conversion rate improved to over 3% (I wish I could show you the resulting data and the pages, but client confidentiality and all that).

The Missing Link (page)

Sometimes, prominent third-party sites link to you. And sometimes they link to you incorrectly. While a good 404 page (see above) can help, you’ll still lose a lot of visitors — they’re clicking a link on a site they trust. When the target site shows a “Page not found” error, the visitor will likely click the “Back” button. In a perfect world, you’d put a custom page at the linked URL, and then use that to gently steer visitors to the right place. Or, you can set up a 301 redirect from the broken URL to the correct one. But how do you find these links? If you’re using a hosted analytics solution like Google Analytics, it won’t report 404 errors out of the box.

A quick look at Google Webmaster Tools, or a little Web server log file analysis, can help you spot these problems. Look for pages that show repeated 404 errors. In the example below, Google Webmaster Tools shows a 404 error from a link placed on 29 different pages. That’s a broken link that begs for redirection or a transition page:

Broken links in Google Webmaster Tools. 29 pages? This one needs a redirect.

This kind of analysis and fix enables defensive design even when you didn’t cause the problem. And again, it lets you build audience, sales and leads without getting new visitors. You’re just improving the experience of current ones.

Avoid Common Mistakes

Walk a mile in your visitors’ shoes, and you will easily be able to avoid the most common defensive design mistakes.

Mistaken Assumptions

Never, ever assume that visitors will “figure it out.” Nor assume that they have any familiarity with your website. Your visitors have plenty of options — the Web’s a big place. Cater to their needs, and be prepared to handle every imaginable mistake. The fewer assumptions you make, the more bulletproof your design will be.

Fake 404s

When you set up your 404 error page, make sure that the server delivers a 404 error code if a page doesn’t exist. Some developers and Web hosts instead redirect users to the 404 error page with a temporary or permanent redirect. The Fail Snail. Image by Todd Bernard

Those redirects deliver a 302 or 301 code, which usually tells search engines to index your error page at many different URLs. I won’t go into the painful details of canonicalization and why this is bad. Take my word for it: the 404 error code was created for a reason. Use it.

Limited Landing Pages

Visitors will come to your website via links, search results and who knows what else. That makes every page a potential landing page. So, practice good defensive design on all of them.

Lousy Copy

Carefully write and edit your copy for inline help, error messages and other contingencies. Your visitors’ patience will already be strained. This is your chance to fix the problem and maybe even start to build a great relationship with them. Make every word count.

Limited Browser Compatibility

Every contingency must work in all browsers. If visitors need the latest browser to see inline help, then it’s not very helpful, is it? Use progressive enhancement to ensure that everyone benefits from every element on the page.

Good For The Brand, Good For The Business

Almost any brand can benefit from good customer service. Defensive design lets you deliver great service effortlessly when your customers need it most. It builds sales and makes customers love you. So, hope for the best and plan for the worst.

It pays to plan for user mistakes and bugs. If you’ve ever managed a website, then you know you’re guaranteed a few bumps along the way. And while putting all of these defensive design measures in place is extra work, it also means more happy visitors. And that means business growth from the audience you have.

Defensive Design: An Experiment

by Zoran Horvat
Sep 26, 2017

We can start from traditional defensive coding techniques and improve code stability significantly. Adding else branch to every if instruction, not forgetting default branch in the switch instruction, checking for null before accessing an object, to name just a few.

But in this article, I plan to oppose these techniques to the defensive design. Primary trait of defensive design is that it removes explicit defensive code. Take a look at the piece of code below. The data variable is, supposedly, some collection of integers.

Which part is defensive in this if-else instruction? – Its else branch is the defensive part. I have no dispute with the if block. I have dispute with part under the else branch. That is what makes the whole situation special. Forgetting the else part would cause erratic behavior. Yet, if-else without else would still be perfectly correct from syntactic point of view.

If only I could make those two sequences of operations same, I would be able to merge if and else branches into one. That would render the condition irrelevant, and I could remove it entirely, together with the if-else instruction which contains them.

And, just to make it clear, condition makes perfect sense here. I could never find minimum out of no data – that operation would fail. Now that situation, that inability to find minimum out of no data, reminds me of a trick, an algorithm called Quick sequential search. Let’s cover that first.

Motivational Example: Quick Sequential Search Algorithm

Below is a straight-forward implementation of sequential search. The function is telling whether the array contains the search value or not.

Loop in this implementation has two branching instructions, and both execute with every iteration of the loop. Now one of these branching instructions, the one inside the loop, is coming from the fact that we don’t know whether the array contains the value at all. And then, when said that way, there comes the Quick sequential search algorithm and says – why don’t we put the search value into the array ourselves? If we do that, then the array will certainly contain the search value.

Look at the alternate implementation. Don’t let it frighten you:

This algorithm is putting the last value from the array aside, and then replacing it with the search value. The point here is that now we know for sure that the array contains the search value. Then the algorithm simply searches for the value, remembering the index at which it was found. Search will always be successful, hence entire loop boils down to one branching instruction. That is how we have simplified the loop by adding the search element to the array. After the loop, we are reconstructing the original array’s content. And then we are simply testing whether we have found our search value, or the value which was there in the original array.

That was quite a lot of code to reduce complexity of the loop. But you get the point. It is possible to tweak the execution context in such way that two execution scenarios become merged into one unified scenario which doesn’t care about differences in the original context.

That idea is greater than this example, this quick sequential search algorithm, which I doubt that anyone has ever really implemented in production. Who knows, maybe it was used somewhere.

Now back to the question of finding the minimum of an array.

Redesigning to Include Defensive Design

Here is the previous piece of code again:

I will start redesigning the code. In the end, I hope to reach a design which is defended out of the box.

The problem is that we can’t take the minimum out of no data. This will not work when data collection is empty. But if we put something into the collection then there will never be the case with no data, right?

This call will never fail, and therefore I don’t have to guard it. The only problem is that from time to time it will return my arbitrarily selected value zero. I will have to keep that in mind for the next step – choosing one out of two possible functions.

Let’s put it precisely that way:

Here is the explanation how this code works. If there is at least one element in the collection, then I want the first function to run. If there is not even one piece of data in the collection, then I want the other function to run. And then, after selecting the function, I just need to collapse this sequence containing exactly one action into the proper action variable.

In the end, the todo variable will contain the precise operation that should be executed. That is why I am simply invoking the todo function unconditionally in the last line of code. Whatever the operation it is, I am safe to invoke it unconditionally.

Don’t judge this code yet. There are better, shorter, more readable ways to accomplish the same goal. I only wanted to show you, as a kind of a mind experiment, that it is possible to completely remove one defensive if-else instruction from code.

What have I got in the end? I have got a unified flow. There is no branching anymore and no defense. Each instruction is producing one single result. Defense has moved deeper under the skin.

The first instruction, which calculates potential minimum, acknowledges that there might be no data to take minimum of, and then it admits, through the name of the variable, that its result might not really be the minimum I needed.

Improving the Defensive Design

Is this code defended better? It almost is. Its strongest point is in the middle part, determining the action. I could improve it a bit by calculating the minimum only in place where it’s already known for sure that the minimum exists:

If you forgive me the utterly ugly syntax, which obviously contradicts usual suggestion that the code should be readable, you will agree at least about one thing: About how hard it has become for me to make a mistake. This code is defended by design.

And readability can be fixed. Here is a better syntax which does the same thing:

The point of this experiment is that we can acknowledge existence of two execution paths and then merge them into one, so that downstream operations have no idea how they got that one execution stream coming their way. You will be better off on more than one account if you can accomplish that.

See Also:

If you wish to learn more, please watch my latest video courses

Beginning Object-oriented Programming with C#

As the course progresses, you will learn such programming concepts as objects, method resolution, polymorphism, object composition, class inheritance, object substitution, etc., but also the basic principles of object-oriented design and even project management, such as abstraction, dependency injection, open-closed principle, tell don’t ask principle, the principles of agile software development and many more.

Design Patterns in C# Made Simple

In this course, you will learn how design patterns can be applied to make code better: flexible, short, readable.

You will learn how to decide when and which pattern to apply by formally analyzing the need to flex around specific axis.

Refactoring to Design Patterns

This course begins with examination of a realistic application, which is poorly factored and doesn’t incorporate design patterns. It is nearly impossible to maintain and develop this application further, due to its poor structure and design.

As demonstration after demonstration will unfold, we will refactor this entire application, fitting many design patterns into place almost without effort. By the end of the course, you will know how code refactoring and design patterns can operate together, and help each other create great design.

Mastering Iterative Object-oriented Development in C#

In four and a half hours of this course, you will learn how to control design of classes, design of complex algorithms, and how to recognize and implement data structures.

After completing this course, you will know how to develop a large and complex domain model, which you will be able to maintain and extend further. And, not to forget, the model you develop in this way will be correct and free of bugs.

About