For a large percentage of human endeavors there are fundamental principles, laws in some cases, which we can use to understand all sorts of phenomena, behaviors and results. We humans have been developing software for approximately 50 years. Over that time a few basic truths, or even laws, have emerged; being aware of these truths can provide insight and understanding. My experience with knowledge of these “laws” is that some events and projects are less of a puzzle to comprehend. In a preface article of the book “Exploring Scrum: The Fundamentals” Jeff Sutherland, co-creator of Scrum, discusses three “Laws”: Ziv’s law, Humphrey’s Law and Conway’s Law. I have heard of Conway’s law but Ziv’s and Humphrey’s are new to me. In addition to these three laws, I have encountered elsewhere some “laws” over the years that seem fairly constant and reliable.

Ziv’s law states that software development is unpredictable and that specifications and requirements will never be fully understood. If one agrees that the fundamental nature of software development is essentially new product design then this law seems valid. When you are creating something new, regardless of the amount of similarity to what has been created before, it is impossible to be certain of all the needs and constraints. We can forecast with varying degrees of accuracy, and should caveat all forecasts with a degree of certainty, but we really cannot predict precisely all the functional and non-functional requirements. The topic of uncertainty is also addressed in Humphrey’s law.

Humphrey’s law states that users do not know what they want until they see working software. We often hear end users say “I’ll Know It When I See It” (IKIWISI). As users interact with a new software system they become more knowledgeable about system potential and functionality. The iterative review and suggestion process leads to further unpredictable discoveries. These new discoveries are, to me, the reason that in development the use of traditional project management approaches are not a good fit, not as effective as other approaches. Traditional project management approaches incorrectly assume the users know what they want before the software is developed.

Conway’s Law states that a software system will reflect the organizational structure of the team developing the software. If the development team does not communicate well then the components of the software system will likely also not communicate well. This is understandable when one considers that software development is a very human intensive process with a multitude of decisions and interactions required. Conway’s Law has been around for many years, dating back to the 1960’s.

I have my own law, which may actually be adapted from someone else’s law (and if so, my apologies): Al’s Law. My law, or Al’s law, states that people will remember slipped dates but not slipped features. If deliveries are made to meet deadlines, even if the deliveries do not include all the promised functionality you are less likely to get into trouble than if you had delivered all the functionality but at later date. I claim this “law” is one of the reasons Agile approaches are sometimes effective. All Agile approaches require delivery on a regular schedule of no more than a few weeks. If you regularly deliver production quality code on promised dates end users and customers will tend to be forgiving, even if some planned features and bug fixes are not delivered on that date. I think this is especially true if the users are accustomed to getting most deliveries late having often experienced frequent schedule slips. For some end users, getting anything on a regular basis, and not necessarily everything, can leave them delighted.

A law that has been around a number of years and originated with Tom Gilb states that “if you don’t attack the risks, the risks will attack you.” Again, considering that software development is essentially the design of a new product it is inescapable there is some amount of risk in every project. Further, ignoring risks does not negate these risks, only that they will not be taken into consideration and managed. If these risks are not monitored they can evolve into real problems that are likely to “attack” you. When something has risks, these risks should not cause you to avoid pursuing the project, nor to pursue the project and ignore the risks and what they can become.

While thinking about these “laws” it occurred to me there is another “law” I have encountered. Many years ago (around the early 80’s) as a graduate student at the Naval Postgraduate School I took a course in Software Engineering. The instructor, Professor Gordon Bradley, made a statement that has stuck with me ever since. He said “software evolves or it dies.” I have found this statement to be truthful in many instances over the years. I think about some of the commercial products I used that were not significantly modified and enhanced over time and notice that they are no longer available. On the other hand some others have been enhanced and revised and are still around. Likewise I have seen business systems that have fallen out of use because they were not enhanced or extended. I therefore submit that such a thing as “Bradley’s Law” exists and is another tool to understand software and software development.