What is the Hyrum’s Law? and Why Should Software Engineers Care?
Hyrum’s law is one such concept that software engineering lecturers find difficult to explain in the classroom environment. Few students have the necessary experience and exposure to software maintenance operations that the law refers to. Furthermore, if one wishes to use them for software engineering assignments, the costs and benefits described in the law are not immediately clear. Despite these challenges, I’ve opted to incorporate them into my Software Engineering course. This is mostly because this law teaches students how to distinguish between clean and clever codes and when to choose one over the other.
Before we get into the specifics of Hyrum’s Law, let us know who Hyrum is and how this law has been popularized among software developers. Hyrum Wright is a senior software developer at Google. (I believe this is his official page) . This law is well known because of the book Software Engineering at Google by Titus Winters and others. In the book, this law, which accurately captures a valuable insight into the nature of “Implicit Dependencies,” is referred to as Hyrum’s law.
This law indirectly refers to some of the best practices that have been shared by practitioners over time, as well as the fact that software engineers rely on them. The practices to which the law refers are: separating interfaces from implementations and design by contract.
During software development, the principles of design by contract and separating interface from implementation are frequently followed through the documentation of Application Programming Interfaces (API) or function signatures. In this context, API consumers and contract publishers are the code elements with dependencies via published contracts. Further, the law observes that reliance by developers on published contracts only is a risky maintenance affair when there are a sufficient number of API consumers exist.
The Hyrum’s Law
The law says that:
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody.
Published contracts, or API, and observable behaviours are the two important ideas that are crucial to understanding this law. especially from the perspective of undergraduate students lacking any software maintenance experience.
The name of the API, input and output data types define the published contract, while actual values of input and output data govern the observable behaviour. The following example illustrates the difference between a published contract and observable behaviour.
Example: Published contract vs observable behaviour
The task of displaying a hash set in Python illustrates the difference between a published contract and its observable behaviour. When a function with the below signature is run on a different Python interpreter, the same HashSet data will be shown in a different order.
void displayHashSet(HashSet mySet): A published contract or API
Observable behaviour
When observable behaviour is non-deterministic, assuming any specific behaviour is a major flaw. In this particular example, assuming a random order or a specific order (e.g., sorted data) is a common mistake that a software maintenance engineer makes.
When the number of people using the system increases, Hyrum’s law issues a warning about the possibility that there is someone who relies on observable behaviour in addition to written contracts. Ignoring this truth will result in those API consumers becoming useless.
In addition to the returned data ordering, external behaviour is manifested in different ways. These are: (I) the format of the data (e.g., MM/DD/YYYY or DD/MM/YYYY are commonly used data formats), (ii) the payload returned during message transfer, (iii) the response time of message transfer; (iv) error code returned and similar returned data characteristics.
In light of this, a software engineer who is tasked with the maintenance of a system that has a longer lifespan and sufficient high usage needs to take into consideration observable behaviour in addition to the written contract.
Takeaways
- Hyrum’s law is applicable in the context of maintaining a system with a longer lifespan and sufficient high usage.
- It differentiates between published contracts and observable behaviour.
- Ignoring observable behaviour may result in API consumers relying on them as useless.
