Automation Principles – Principle of Least Astonishment

This is part of a series of posts to understand Network Automation Principles.

The Principle of Least Astonishment or Principle of Least Surprise describes the contract between the developer and another party such as a user, another developer, or contributor. The principle is based on two underlying rules about code:

• People are part of the system. The design should match the user’s experience, expectations, and mental models.
• A component of the principle means that a component of a system should behave in a way that most users will expect it to behave; the behavior should not astonish or surprise users.

To give a few contrived examples:

• A function called add_vlan() should not configure all switchports for that VLAN.
• Issuing the command switchport trunk allowed vlan add 100 should not remove other VLANs from the port.
• Adding a row to a database table does not remove the table and recreate it.

Real World Application

In your daily life, there are countless examples of how this applies. How navigation bars work, how to exit a program, what a clicked link should look like, etc. When a process does not follow the principle, it often leaves the user confused or frustrated.

Even decades later Windows XP, though dated, is still lauded for it’s design. This is in large part since every application within the system followed the same rules. There was always a single top navigation bar that indicated what the shortcut key was by underlining a letter. Later, Microsoft office would introduce a ribbon in lieu of that standard navigation bar and remove the underline indicator. Individually, you can argue that the new systems are better, but as a whole the user does not have a consistent feel.

View this example, taken from a uxmovement article.

The selected styling on the left does not indicate clearly which is selected, as it does not build on your previous experience, but rather your understanding of the single site’s styling.

Network Automation Application

While not exactly specific to network automation the read the docs rendering style, which is an implementation of sphinx, has become somewhat of a de facto standard within the industry. In any given instance, I suspect there is a better user experience, but if you are accustom to many of the tools used in network automation such as NetBox, NAPALM, or Ansible and Python libraries such as requests, flask, and netaddr then having a consistent structure and components lowers the barrier to entry and sets expectation for users.