Some Laws of Software Development

April 30, 2017 — Posted by Al Shalloway

This blog has been moved to our Portal here.

This blog continues my series on Going Beyond Practices to Achieve Objectives

There is a significant difference between a law and a principle.  In Values, Practices and Principles Are Not Enough we defined them as:

  • Principle – a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning
  • Law – (natural laws) a statement of fact, deduced from observation, to the effect that a particular natural or scientific phenomenon always occurs if certain conditions are present

Principles and laws 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 whereas laws are just the way things are.  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. 

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:

  • The time from getting a requirement until validating it increases the likelihood that work will be done that was not the intention of the person creating the requirement
  • The time from creating a bug until detecting it increases the time to fix it

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. 

One of the more important “laws” that affects software development and is 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.

Almost 7 years ago I wrote a blog called Yes Virginia, You Can Attribute Cause-and-Effect even in Complex Adaptive Systems.  Here are several laws from that blog.  This is not meant to be a complete list. 

Some laws regarding knowledge management:

  • Distrusting well intended, competent people will cause their behavior to be less useful than if you trust them 
  • If you distrust people and pretend you trust them, they will eventually figure out that you distrust them
  • Over-working people lowers their efficiency
  • If you treat people poorly, they will not work as hard for you as they would otherwise
  • People working on too many items lowers both their productivity and their resolve to do better
  • if you reward people based on particular measures, they will work more towards those measures than they will towards what you really want
  • if people ignore principles that effect their work, they will get inferior results than if they attend to them
  • if people don't have compatible visions of the future, they will not work as well together as a team whose members have a compatible vision
  • if people disagree on what is important and don't try to resolve the disagreement or work with it, this disagreement will cause challenges
  • people on a team attending to what they like instead of what works, lowers the functionality of a team

Some  laws specific to software development:

  • Not defining or validating acceptance tests with the customer (or their rep) before writing code tends to cause wasted effort
  • Not attending to code quality results in the degradation of the code over time, increasing it’s cost to maintain
  • When a developer writes code attending to only how they like code to be written, their teammates will have more trouble understanding it than if they attended to how their teammates will understand the code
  • Using archaic names for your code variables makes it harder for people (including the author) to understand the code’s intention than if intention revealing names were used
  • The time it takes to perform an integration is correlated to the period of time between integrations
  • if you don't get customer feedback quickly, you will write code a lot of code they really don't want (for any number of reasons)

Some laws regarding management:

  • if managers can't see what you are doing, they won't understand what you are doing (this does not imply they will understand it by just seeing it)
  • if managers ask you to do one more thing in your iteration and they don't know your process (or you don't have an explicit one) then when you say you can't squeeze it in they will likely think you just aren't willing to take the extra effort required
  •  if you treat managers without respect, you will get less respect in return

For the most definitive collection of laws and principles regarding product development, see Don Reinertsen’s The Principles of Product Development Flow: Second Generation Lean Product Development.

In Conclusion

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. 


Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban