Principles, Laws and Adages
There is a significant difference between a principle and a law.
Principles, laws and adages are sometimes confused with each other. The significant difference is that principles are followed to achieve one’s goals or to justify one’s belief systems, laws are the way things are and adages are the way things will be if you don’t do something about it. Laws are often forces, such as the “law of gravity” which can be overcome by other laws (e.g., satellites stay in orbit because the “law” of gravity is compensated by the “law” of centrifugal force. The key is that laws affect you whether you attend to them or not.
An example of the relationship between principles and laws is the guidance provided by the principle of working towards quick feedback. The law behind this principle is that “delays in obtaining and using feedback creates work that would otherwise not need to be done.” There are many examples of this, including:
Some things are called laws which really aren’t. For example, Murphy’s Law that “anything that can go wrong will go wrong.” Some people like to add “and at the worst possible time.” This of course, is not a real law, but it is worth acting as if it were.
Many “laws” may not be as well-defined as say the law of gravity. But they are true enough that they should be attended to. Doing so can often alleviate their adverse effects. For example, one of the more important “laws” that affects software development, but is unfortunately mostly ignored is Conway’s Law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” Conway’s law is a force that if left unchallenged results in poor architectures when the organizational structure and technical habits of the development teams are not attended to well.
This is not meant to be a complete list.
Some laws or adages regarding knowledge management
Some laws or adages specific to software development
Some laws or adages regarding management
For the most definitive collection of laws and principles regarding product development, see The Principles of Product Development Flow: Second Generation Lean Product Development by Don Reinertsen.
Applying Laws in a Complex System
Many in the Agile community believe that laws don’t exist in software development because it is a complex system. However, I believe that there are laws that virtually always apply. But laws in a complex system may not always appear to apply because other factors are at play – sometimes unknown factors. For example, I believe that if people work on too many things their efficiency goes down. But if they are not a limiting factor on value delivery it may not make any difference.
However, it is not worth debating whether these are true laws or not. It is worth acting as if they were, but validating them just in case we are mistaken. Sometimes even when we discover a law and apply it properly we may miss another law that also applies. This would not be unlike when the designers of the Tacoma Narrows Bridge didn’t attend to wind velocity and insufficient redundancy in the stays of the bridge. And then sometimes people will respond in a way that is not anticipated and essential block what would have been an improvement. But not attending to laws will definitely make positive change harder.
One must attend to the laws of knowledge work in general and software development in particular in order to be effective and/or efficient. Our beliefs about them do not change how they affect us. Part of Agile’s focus on “inspect and adapt” must be about learning how we are being affected by laws we are not paying enough attention to.
If you want to learn more about FLEX you can take an online course at the Net Objectives University or take a live course in Orange County, CA May 6-8 or in Seattle in June (both led by Al Shalloway). If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway