Avraham is a Senior Architect with Cisco tasked with designing complex PayTV systems. He also researches and teaches theory of software development. He is currently studying, writing and teaching on the complex relationships between the organizations that create software and the software they create.
Most software that performs non-trivial tasks, is complex. We understand that and welcome that. However, we often feel that much of the software we design, create and deploy is more complex than need be, or “unnecessarily complex“. We are constantly trying to figure ways of reducing this “accidental complexity”.
In 1968 Melvin Conway published the idea that there is a “very close relationship between the structure of a system and the structure of the organization which designed it.” Over the decades, this law has repeatedly been observed to be true. This law has many implications that if properly considered, might allow us to make software design simpler, and if ignored will make our software more complicated than need be. You can ignore or even fight Conway’s law by trying to create software that does not correlate to the organizational structure. But Conway’s law will always be there and will almost always win.
This thought provoking talk explores the roots of the complexities through the prism of “Conway’s law”. In this talk Avraham presents some of the implications of Conway’s law as well as theoretical limits to the reduction of complexity. Understanding those limits can help us better focus expectations and hence our resources.
Commonality Variability Analysis (CVA) is the part of domain analysis that focuses on how things remain the same, and how things change. For example, every useful function has the constant part that is the “behavior” of the function, and the variable part that is the parameter of the function. All software design assumes that certain things are constant (and that theses constants are known at coding time), and therefore there is value to writing code that will keep running, and there are certain things that change (or not known at coding time) and that is why the code is parameterized.
Whether done explicitly or implicitly, CVA is THE core principle underlying all software development. Complexity in software design is addressed through CVA.
When it comes to domains, domains rarely stay the same, otherwise there would be no need to upgrade our software. At the domain level CVA should include analysis of how the domain is likely to evolve over time. What will stay fixed, and what will change. That way we can make certain parts of our system tolerant of change.
Done properly, we will have software that is flexible in the right places, and rigid in the right places. That allows for stable software that accommodates change. Done improperly, we have software that is fragile and brittle, that can only be changed with great investment.
What about Conway's law? As we saw in the talk, Conway’s law is not only a statement about homomorphism, it is a statement about complexity. Do Conway’s law and CVA have anything to do with each other? I argue that they do. For example, domains change over time, and our software might need to change over time to accommodate. Some of these changes might be structural changes. Does Conway’s law mean that we might need to constantly change our organization as the domain evolves?
In this hands on session, I would like to give a quick overview of the basic concepts surrounding CVA (Positive and Negative Variance, Binding time etc), and then dive into thought experiments that will explore how can we do CVA in a way that not only takes Conway's law into account, but even harnesses it to our advantage.
The exercises will give the participants opportunity to explore the following.
CVA – How do the various commonalties and variabilities express themselves in documentation, interfaces, code, deployed software and configuration files?
Scaffolding – can we articulate heuristics for what parts of a system should be rigid and what parts should be flexible.
Changing organization. What do we do when a organization changes for a reason that is not related to the software design. Do we keep the software the way it is, or do we change to account for Conway’s law. If we anticipate such a change, are there variances/flexibilities that we can put in place to accommodate??
The cost of errors – what is the cost if I assume something will change, but it does not change. What is the cost if I assume something will change and it ends up being constant. What happens if I make a mistake in the binding time? Are there certain mistakes that are safer than others?
Given the real world we live in, are there steps we can do to simplify our organizations that will make the software we design less complex?
