Remembering Ashton’s Law

The very first class I took when starting my computer science degree from Brigham Young University was CS 131. I forget the course title, but the teacher was Dr. Alan Ashton, a quiet, self-effacing but brilliant professor who would later become very, very rich by developing — along with Bruce Bastian (with whom I shared a TA office for an entire school year) — the WordPerfect word processing program.

Dr. Ashton was an outstanding instructor. I took this class in 1974, and all our programming was done on an IBM 360/65 mainframe in 360/Assembly, on punched cards no less. Yet Dr. Ashton thoroughly inculcated in us the concepts of structured programming, having us (for example) come up with half a dozen different ways of implementing a WHILE loop in assembler.

At the same time, he did his best to teach us the realities of software development and engineering. One of his comments in class seemed so axiomatic that I immediately thought of it as “Ashton’s Law” and have quoted it as such ever since:

Ashton’s Law: Whenever someone tries to do something for you, they usually end up doing it to you.  — Dr. Alan Ashton, 1974

I have long lost track of how many times over the past 34 years I’ve thought of Ashton’s Law or have spoken it out loud to others. Dr. Ashton made the comment in the context of operating systems, software tools, and applications; all we have to do is look at something like the User Account Protection in MS Vista to see that Ashton’s Law is all too much alive and well.

But there is a deeper issue here in software design and implementation, which I’m also sure Dr. Ashton had in mind. When two software components have to interact, there is usually an explicit and documented (by the source code itself, if by no other means) interface for one component (the ‘called’ component, for lack of a better term) that the other (the ‘calling’ component) makes use of.

In designing functions or services of the called component, we often end up as perpetrators of Ashton’s Law. That is, in our desire to do something for those who will invoke these functions or services, we end up doing something to them.  We make decisions about preconditions, calculations, and results that may seem quite reasonable to us, and that we may have the best intentions for; still, our decisions may lead to others cursing our names (or at least our functions).

There are always tradeoffs in software development among such desirable features as reliability, performance, memory footprint, calling/service standards, security, simplicity, and so on. Our priorities — even our requirements — may differ from those who will use our component’s functions and services, and so a certain amount of friction is perhaps unavoidable. What we can do is spell out all our assumptions and restrictions, and the reasons behind them, so that those using our functions and services know what they’re getting (or not getting).

However, there may exist also what is variously termed a deep, hidden or undocumented interface for the called component. This deep interface deals with invisible and often unknown requirements, side effects, and consequences of a given function or service provided by the called component. For example, the function or service may leave some aspect of the software system or the host computer system in a different state (e.g., changes to internal data structures, changes to files or databases, launching or killing of processes, and so on) without making that fact explicitly clear in any documentation or the API itself. You may feel there is a good reason for this, but it may also interfere with the calling component’s on-going functions.

As with much of what I post here, this may seem quite obvious to you, but trust me — obvious or not, it’s incredibly common and quite frustrating for those having to use the offending software. As software engineers creating software components, systems, and applications to be used by others, we need to constantly keep Ashton’s Law in mind and ensure that we are truly developing useful functionality for others instead simply making their lives more difficult.  ..bruce..

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.