48 Laws, Rules, and Principles of Web Development

Published on June 7, 2023 (↻ August 17, 2024), filed under Development (RSS feed for all categories).

In anticipation of the upcoming release of The Web Development Glossary 3K (the new edition of The Web Development Glossary), here are four dozen laws, rules, and principles related to web and software development.

How many do you know?

Amdahl’s Law

A formula which gives the theoretical speed-up in latency of the execution of a task at fixed workload that can be expected of a system whose resources are improved. Amdahl’s Law states that “the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used.” It is named after computer scientist Gene Amdahl, and was first presented in 1967.

Boyscout Rule

The idea to “always leave code better than you found it,” which may be attributable to Robert C. Martin.

Bushnell’s Law

Nolan’s Law

An aphorism attributed to Atari founder Nolan Bushnell, on the subject of video game design: “All the best games are easy to learn and difficult to master. They should reward the first quarter and the hundredth.” This is also referred to with the sentence “easy to learn, hard to master.”

Command-Query Separation

A principle of imperative computer programming. CQS was devised by Bertrand Meyer as part of his pioneering work on the Eiffel programming language. The principle states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, “Asking a question should not change the answer.” More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.

Conway’s Law

The adage that organizations design systems that mirror their own communication structure. Conway’s Law is named after computer programmer Melvin Conway, who introduced the idea in 1967. His original wording was: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

Don’t Repeat Yourself

A principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy. The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” The principle has been introduced by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer.

Curly’s Law

“Just one thing,” a film character’s advice from the movie City Slickers. Curly’s Law is sometimes used instead of, or as a corollary to, the Single Responsibility Principle.

Dependency Inversion Principle

A specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level policy-setting modules to low-level dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states 1) that high-level modules should not depend on low-level modules, but that both should depend on abstractions (e.g., interfaces), and 2) that abstractions should not depend on details, but that details (concrete implementations) should depend on abstractions.

Even-Odd Rule

An algorithm implemented in vector-based graphic software, like the PostScript language and Scalable Vector Graphics (SVG), which determines how a graphical shape with more than one closed outline will be filled. Unlike the non-zero rule algorithm, this algorithm will alternatively color and leave uncolored shapes defined by nested closed paths irrespective of their winding.

Fifth Rule of ARIA

“All interactive elements must have an accessible name.” w3.org/TR/using-aria

First Rule of ARIA

“If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.” w3.org/TR/using-aria

Fitts’s Law

A predictive model of human movement primarily used in human-computer interaction and ergonomics. This scientific law predicts that the time required to rapidly move to a target area is a function of the ratio between the distance to the target and the width of the target. Fitts’s Law is used to model the act of pointing, either by physically touching an object with a hand or finger, or virtually, by pointing to an object on a computer monitor using a pointing device. Fitts’s Law has been shown to apply under a variety of conditions.

Fourth Rule of ARIA

“Do not use `role=”presentation”` or `aria-hidden=”true”` on a focusable element.” w3.org/TR/using-aria

Goodhart’s Law

An adage often stated as, “When a measure becomes a target, it ceases to be a good measure.” It is named after British economist Charles Goodhart, who is credited with expressing the core idea in a 1975 article on monetary policy in the United Kingdom: “Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”

Hick’s Law

Hick-Hyman Law

A model describing the time it takes for a person to make a decision as a result of the possible choices they have, asserting that increasing the number of choices will increase decision time logarithmically. Hick’s Law assesses cognitive information capacity in choice reaction experiments. The amount of time taken to process a certain amount of bits in the Hick-Hyman law is known as the rate of gain of information.

Interface Segregation Principle

The principle that no client should be forced to depend on methods it does not use. ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.

Inversion of Control

A programming principle that inverts the flow of control as compared to traditional control flow. In IoC, custom-written portions of a computer program receive the flow of control from a generic framework. A software architecture with this design inverts control as compared to traditional procedural programming, where the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks. With inversion of control, it is the framework that calls into the custom, or task-specific, code.

Jakob’s Law

“Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.”

Law of Conservation of Complexity

Tesler’s Law

An adage in human-computer interaction stating that every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction, which poses the question of who should be exposed to the complexity. For example, should a software developer add complexity to the software code to make the interaction simpler for the user, or should a user deal with a complex interface so that the software code can be simple?

Law of Demeter

Principle of Least Knowledge

A design guideline for developing software. In its general form, the Law of Demeter is a case of loose coupling. The guideline was proposed in 1987 by Ian Holland at Northeastern University. It can be summarized through three recommendations: 1) Each unit should only have limited knowledge about other units. 2) Each unit should only talk to its friends; don’t talk to strangers. 3) Only talk to your immediate friends.

Law of Leaky Abstractions

An abstraction that reveals details that it is supposed to abstract away. As stated in 2002 by Joel Spolsky in the “Law of Leaky Abstractions”: “All non-trivial abstractions, to some degree, are leaky.” The statement highlights a particularly problematic cause of software defects, namely the reliance of the software developer on an abstraction’s infallibility. While abstractions try to hide complexity, the law claims that developers of reliable software must learn the abstraction’s underlying details anyway.

Liskov Substitution Principle

A particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced in 1987 by Barbara Liskov. The Liskov Substitution Principle is a semantic rather than merely syntactic relation, because it intends to guarantee semantic interoperability of types in a hierarchy, particularly of object types. Liskov’s notion of a behavioral subtype defines a notion of substitutability for objects; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g., correctness).

Little’s Law

A theorem by John Little which states that the long-term average number L of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system: L = λ/W. The result applies to any system, and particularly, it applies to systems within systems.

Muphry’s Law

An adage that states: “If you write anything criticizing editing or proofreading, there will be a fault of some kind in what you have written.” The name is a deliberate misspelling of “Murphy’s Law.”

Murphy’s Law

An adage or epigram that is typically stated as: “Anything that can go wrong, will go wrong.”

Ninety-Ninety Rule

A humorous aphorism attributed to Tom Cargill that states: “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” This adds up to 180%, making an allusion to the notoriety of software development projects significantly over-running their schedules.

Non-Zero Rule

Non-Zero Winding Rule

A means of determining whether a given point falls within an enclosed curve. Unlike the similar even-odd rule, it relies on knowing the direction of stroke for each part of the curve. The SVG computer graphics vector standard uses the non-zero rule by default when drawing polygons.

Open-Closed Principle

The idea that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification,” that is, that such an entity can allow its behavior to be extended without modifying its source code.

Orthogonality

A software design principle meaning that change of one piece of software does not affect other pieces, or that operations do not have side effects. Orthogonality in a programming language means that a relatively small set of primitive constructs can be combined in a relatively small number of ways to build the control and data structures of the language. It is associated with simplicity; the more orthogonal the design, the fewer exceptions. This makes it easier to learn, read and write programs in a programming language. The meaning of an orthogonal feature is independent of context; the key parameters are symmetry and consistency (for example, a pointer is an orthogonal concept).

Pareto Principle

The observation that for many events, roughly 80% of the effects come from 20% of the causes. It is named after Italian economist Vilfredo Pareto, who noted the 80/20 connection in 1896, as published in his first work, Cours d’économie politique. In it, Pareto showed that approximately 80% of the land in Italy was owned by 20% of the population. It is a similar axiom of business management that “80% of sales come from 20% of clients.”

Parkinson’s Law

The idea that work expands so as to fill the time available for its completion. Parkinson’s Law is sometimes applied to the growth of bureaucracy in an organization. It was stated in 1955 by Cyril Northcote Parkinson in an essay published in The Economist. A popular corollary is that “Work contracts to fit in the time we give it.”

Pave the Cowpaths

The idea to build on and formalize existing practices. “Pave the Cowpaths” was one of the design principles used to revisit and extend the HTML standard. webglossary.info/x/ptc

Perceivable, Operable, Understandable, and Robust [counted as four principles]

The four major principles of WCAG 2.0. Information and user interface components must be presentable to users in ways they can perceive; user interface components and navigation must be operable; information and the operation of user interface must be understandable; and content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Peter Principle

A management concept developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to “a level of respective incompetence”: Employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another. The concept was explained in the 1969 book The Peter Principle by Laurence Peter and Raymond Hull.

Postel’s Law

Robustness Principle

“Be conservative in what you send, be liberal in what you accept.” Also known as the Robustness Principle, it is named after Jon Postel, who wrote in an early specification of TCP that “TCP implementations should follow a general principle of robustness: Be conservative in what you do, be liberal in what you accept from others.”

Principle of Least Astonishment

Principle of Least Surprise

The idea that a component of a system should behave in a way that most users expect it to behave. A formal statement of the principle is, “If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.” The principle has been in use since at least the 1970s.

Principle of Least Authority

Principle of Least Privilege

Principle of Minimal Privilege

The requirement that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose. The principle means giving a user account or process only those privileges which are essential to perform its intended function.

Second Rule of ARIA

“Do not change native semantics, unless you really have to.” w3.org/TR/using-aria

Separation of Concerns

A design principle for separating a computer program into distinct sections such that each section addresses a separate concern. A concern is a set of information that affects the code of a computer program. A concern can be as general as the details of the hardware for an application, or as specific as the name of which class to instantiate. A program that embodies SoC well is called a modular program. Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface. Layered designs in information systems are another embodiment of separation of concerns (e.g., presentation layer, business logic layer, data access layer, persistence layer). Separation of concerns results in more degrees of freedom for some aspect of the program’s design, deployment, or usage.

Service Statelessness Principle

A design principle that is applied within the service-orientation design paradigm, in order to design scalable services by separating them from their state data whenever possible. This results in reduction of the resources consumed by a service, as the actual state data management is delegated to an external component or to an architectural extension. By reducing resource consumption, the service can handle more requests in a reliable manner. The correct application of service statelessness requires an understanding of the various types of state information that need to be managed, like context, business, or session data.

Single Responsibility Principle

A computer programming principle that states that every module, class, or function should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the module, class, or function. All its services should be narrowly aligned with that responsibility.

SOLID [mentioned, but not counted given that the individual principles have been covered]

A mnemonic acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. SOLID refers to 1) the Single Responsibility Principle, 2) the Open-Closed Principle, 3) the Liskov Substitution Principle, 4) the Interface Segregation Principle, and 5) the Dependency Inversion Principle. SOLID represents a subset of software development principles promoted by Robert C. Martin.

Ten-Second Rule

A rough limit for user attention. After ten seconds, the probability is deemed to increase that users start to engage in other activities, or abandon a process or site.

Third Rule of ARIA

“All interactive ARIA controls must be usable with the keyboard.” w3.org/TR/using-aria

Three-Click Rule

An unofficial, debunked web design rule concerning the design of website navigation. The Three-Click Rule suggests that a user of a website should be able to find information with no more than three mouse clicks. It is based on the belief that users of a site will become frustrated and often leave if they cannot find the information within three clicks. The rule has explicitly been called out as false by usability specialists Nielsen Norman Group.

You Aren’t Gonna Need It

A principle of Extreme Programming (XP) that states that a programmer should not add functionality until deemed necessary. Quoting XP co-founder Ron Jeffries, “Always implement things when you actually need them, never when you just foresee that you need them.” Other forms of the phrase include “You aren’t going to need it” and “You ain’t gonna need it.”

Most explanations are based on Wikipedia. Sources as linked, but also listed in the Appendix of The Web Development Glossary (PDF) as well as The Web Development Glossary 3K. This post is licensed under a CC BY-SA 4.0 (Attribution-ShareAlike 4.0 International) license.

The Web Development Glossary 3K is scheduled to be published in July [and is now available]—not only on Leanpub, but also on Apple Books, Kobo, Google Play Books, and other platforms. You can get notified about the release at Leanpub, by subscribing to the meiert.com feed, or by following my updates on networks like Mastodon.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)