The Responsible Designer

Rigor?


Ausschnitte aus 'Rigor Mortis - Der Tod steht uns gut' Theater Akzent
…rigor is a sham if your software is merely performing 'rigor theatre'

This blog post is based on a talk on model rigor I gave at DDDEu 2024.

Before we dive into model rigor, let’s define it. According to the American Heritage Dictionary, definitions for rigor range from strictness or severity to shivering or trembling or stiffness:

  1. Strictness or severity, as in action or judgment.
  2. A harsh or trying circumstance; a hardship or difficulty: synonym: difficulty.
  3. Archaic A harsh or severe act.
  4. Strictness in adhering to standards or a method; exactitude.
  5. A standard or exacting requirement, as of a field of study.
  6. Medicine Shivering or trembling, as caused by a chill.
  7. Physiology A state of rigidity in living tissues or organs that prevents response to stimuli.
  8. Obsolete Stiffness or rigidity.

The only reasonable meaning for rigor in a software model seems to be, “strictness in adhering to standards or a method; exactitude.”

When we talk about strictness in adhering to a method, that could mean that we are precisely following a process or method to model our software, or that we are creating a software model that supports people who need to precisely follow a process or method. (Both are reasonable things to do). But let me be clear: rigor in a software modeling process is different from rigor in a software model. And strictly following a standard process is no guarantee that you will produce a rigorous model.

The second kind of model rigor is exactitude. In software this often boils down to getting a definitive answer to a specific question before proceeding.

For example, consider the question posed on the Mellisoni Vineyards website. (No, Mellisoni Vineyards, I am not picking on you. Really. Your website is just a good example.)

After clicking “shop now” you are asked, “Are you 21 or older? By entering this website, you agree that you're of legal age.” Click “yes” and you can proceed to view their products and make a purchase. Click “no” and you are told, “Sorry, you do not meet the age requirements to access this site.” But, no problem! Hit the browser back button and simply answer “yes” next time to get around that minor stumbling block.

I’m guessing their question only works for bots or toddlers. Is this a rigorous enforcement of an age requirement? Of course not! It’s merely ticking off a box that says, we are appearing to be responsible by asking this question.

In the USA, to legally purchase alcohol, you must be over the age of 21. Some websites that sell alcohol try to prevent children from purchasing or even viewing their products. Many do not. But there is no legal requirement to do so. (For a more nuanced discussion of legal requirements of age verification, see Why Alcohol Websites Make You Enter Your Age)

Since no law requires Mellisoni Vineyards to verify age, why do they ask? Well … since businesses are legally required to not sell alcohol to children, in order to protect their reputation and conform to social pressures, they ask.

This is an example of what I call “rigor theatre.” Appearing to be rigorous when you’re really not. Model rigor is desirable when a precise, exact, definitive answer to a question should determine and constrain future actions. But when it is gratuitously added, it creates extra friction for users, extra work for software developers, and a false sense of having covered your bases.

People will find workarounds to your gratuitous rigor to achieve their goals if those workarounds are simple enough. But if your software places too many constraints on them, they’ll simply stop visiting your site.

Rigor isn’t arbitrary when our software models physical laws or mathematical formulas. But it often seems arbitrary when it is applied to other system behaviors. When do we need strict precision in answers? When is it a bad idea to enforce such rigor? What should we do when it’s too hard to enforce seemingly necessary rigor? These are questions I’ll explore in future blog posts.