Martin Heller
Contributing Writer

Law of Least Astonishment

analysis
Nov 27, 20072 mins

My discussion of software surprises on Saturday reminded me about the Law or Principle of Least Astonishment, also called the Law or Rule of Least Surprise. This certainly goes back to the early days of Unix, if not before: it is discussed in The Art of Unix Programming, by Eric Raymond, which is online here. I'm convinced that the originator of the name of this law had a Physics background. The name is striking

I’m convinced that the originator of the name of this law had a Physics background. The name is strikingly similar to the Law of Least Action, which is the basis of Lagrangian and Hamiltonian mechanics.

Tracking down the origins of the Law of Least Surprise reminded me that I had on my bookshelf at work signed copies of The Tao of Programming and The Zen of Programming, given to me by the author, Geoffrey James, when we were in the same Tai Ji Quan class some years ago.

The entire English text of The Tao of Programming is actually online. Half the pleasure of the book is the Chinese on the facing pages and the layout; that has been lost in the online version. Even though I’ve studied Chinese and still have my dictionaries, I’ve never bothered to translate that Chinese — and I’ve never asked Geoff what I’d find if I did. I’ve also never asked whether he minded the online version of his book.

The passage on the ‘Law of Least Astonishment’ follows:

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity.

A program should follow the ‘Law of Least Astonishment’. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.

A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.

If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program.

Martin Heller

Martin Heller is a contributing writer at InfoWorld. Formerly a web and Windows programming consultant, he developed databases, software, and websites from his office in Andover, Massachusetts, from 1986 to 2010. From 2010 to August of 2012, Martin was vice president of technology and education at Alpha Software. From March 2013 to January 2014, he was chairman of Tubifi, maker of a cloud-based video editor, having previously served as CEO.

Martin is the author or co-author of nearly a dozen PC software packages and half a dozen Web applications. He is also the author of several books on Windows programming. As a consultant, Martin has worked with companies of all sizes to design, develop, improve, and/or debug Windows, web, and database applications, and has performed strategic business consulting for high-tech corporations ranging from tiny to Fortune 100 and from local to multinational.

Martin’s specialties include programming languages C++, Python, C#, JavaScript, and SQL, and databases PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database, Google Cloud Spanner, CockroachDB, MongoDB, Cassandra, and Couchbase. He writes about software development, data management, analytics, AI, and machine learning, contributing technology analyses, explainers, how-to articles, and hands-on reviews of software development tools, data platforms, AI models, machine learning libraries, and much more.

More from this author