Differentiate Between Levels of Concern

We accomplish various goals in code, but the importance of all these goals is not equal. For example, a user presses a button to submit a form. A few things need to happen as a result of that:

• Write some data into the database
• Communicate “hang on, we’re processing” to the user by showing a spinner
• Update some search index based on updated data
• Save a subset of the form fields in user preferences, so that we can prefill them next time

These things are not of equal importance. From the business perspective, it’s vital that we successfully write the data into the database, but displaying a spinner to the user, while useful, is a relatively less important. Saving form fields for prefilling a form later is even less important — the user may not even touch the form a second time.

An important corollary of this difference in importance is: a failure in a less important goal should never prevent success in a more important goal. It is not acceptable that a buggy spinner component (the secondary concern) may prevent data from being written to the database (the primary concern). Likewise, a failure in saving user preferences (a tertiary, or at best secondary concern in this case) must not prevent the database write from succeeding.

It’s important to note that the relative importance of concerns is contextual. In the example above, saving user preferences is at most a secondary concern. But on the user preferences screen, saving user preferences is very much a primary concern.

Next: Prefer Default Deny ⇒