Team Coupling Characteristics
The way firms organize and govern their own structures significantly influences the way that software is built and architected. In this section, we explore the different organizational and team aspects that make building evolutionary architectures easier or harder. Most architects don’t think about how team structure affects the coupling characteristics of the architecture, but it has a huge impact.
Culture, (n.): The ideas, customs, and social behavior of a particular people or society.
Architects should care about how engineers build their system and watch out for the behaviors their organization rewards. The activities and decisionmaking processes architects use to choose tools and create designs can have a big impact on how well software endures evolution. Well-functioning architects take on leadership roles, creating the technical culture and designing approaches for how developers build systems. They teach and encourage in individual engineers the skills necessary to build evolutionary architecture.
An architect can seek to understand a team’s engineering culture by asking questions like:
- ? Does everyone on the team know what fitness functions are and consider the impact of new tool or product choices on the ability to evolve new fitness functions?
- ? Are teams measuring how well their system meets their defined fitness functions?
- ? Do engineers understand cohesion and coupling?
- ? Are there conversations about what domain and technical concepts belong together?
- ? Do teams choose solutions not based on what technology they want to learn, but based on its ability to make changes?
- ? How are teams responding to business changes? Do they struggle to incorporate small changes, or are they spending too much time on small business change?
Adjusting the behavior of the team often involves adjusting the process around the team, as people respond to what is asked of them to do.
Tell me how you measure me, and I will tell you how I will behave.
Dr. Eliyahu M. Goldratt (The Haystack Syndrome)
If a team is unaccustomed to change, an architect can introduce practices that start making that a priority. For example, when a team considers a new library or framework, the architect can ask the team to explicitly evaluate, through a short experiment, how much extra coupling the new library or framework will add. Will engineers be able to easily write and test code outside of the given library or framework, or will the new library and framework require additional runtime setup that may slow down the development loop?
In addition to the selection of new libraries or frameworks, code reviews are a natural place to consider how well newly changed code supports future changes. If there is another place in the system that will suddenly use another external integration point, and that integration point will change, how many places would need to be updated? Of course, developers must watch out for overengineering, prematurely adding additional complexity or abstractions for change. The Refactoring book contains relevant advice:
THREE STRIKES AND YOU REFACTOR
The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor.
Many teams are driven and rewarded most often for delivering new functionality, with code quality and the evolvable aspect considered only if teams make it a priority. An architect that cares about evolutionary architecture needs to watch out for team actions that prioritize design decisions that help with evolvability or to finds ways to encourage it.