Chris Lucian

Recently Nicholas U had a question about emergent architecture that I would like to address in this blog.

“Emergent architecture really is a tough topic. You certainly have much experience on this field, and you view on the emergent architecture process looks quite extreme, that is, really emergent. I would be interested in having some examples of how you successfully applied it, and if there are some "limits" that you encountered regarding the emerging architecture.”

The bottom line is that emergent architecture is a reward for having a safe environment.  Both technical and psychological safety are required to provide a foundation for a malleable design. Ivory tower architecture is a result the lack of both types of safety. A team may believe it is too expensive to change the architecture of an application to increase maintainability.  A team also may have someone who does not acknowledge their fallibility. In both these cases ivory tower architecture begins to seem like the way to progress forward. Instead we strive to create an environment where it is safe to change your mind and acknowledge that we don’t know what the requirements will be when changes happen to scope. Once you have that foundation a Mob Programming team can discuss and evolve architecture as the system develops over time. Ultimately the goal is agility but we achieve it through safety.

Emergence is no excuse for ignoring generic proven computer science and technical excellence practices. In a previous blog I note our core development process. Notice the questions after functionality is written. “Is it cohesive?”, “Is it loosely coupled?” we expect our teams to always ask these questions between tasks and refactor regularly to make sure that the decisions do not land us in a bad situation. With that said, it must be very safe to make changes and have confidence that the change will not break existing functionality. We also should be able to say with confidence that we are using tools for the job that are adequate. It is not necessary to have the perfect choices, only to be able to say we are not using the wrong tools for the desired functionality. Finally, I believe it is important to have dedicated learning time scheduled for developers. For example, we have 7 hours a week dedicated to learning time in which the developers are able to find new technologies and hone their skills in existing technologies. When architecture changes regularly, there needs to be slack in the system for all developers involved to keep their skills sharp in each new paradigm they must work in.

Ask yourself: How long does it take your team to find out there is a bug in your software? A big factor on how agile a team can be is how quickly they get feedback. Continuous Integration utilizing end to end tests can quickly expose deficiencies in an architecture. Vice tests using approvals or gold standard testing can give quick feedback if a control flow has been violated. These are two types of safety that can make quick decision making a much less expensive activity.

When you have automated end to end tests and high coverage vice tests in place you can refactor. At any point during any project there may be a change in scope that will make it evident that the existing architecture is inadequate in some way for the new requirement. It is unhealthy to assume that the architecture is impervious to this type of change. Therefore it is evident that the team should invest in making the environment safe to make technical changes along the way.

In the TED talk above Amy Edmondson talks about 3 ways to create psychological safety in a workplace.

For any leader, technical or otherwise, the existence of psychological safety is extremely important to emergent architecture. In the TED talk she also talks about impression management which leads to creating an environment without psychological safety.

She states, “No one wants to come into work to look Ignorant, Incompetent, Intrusive, and Negative.” To mitigate these issues one can just not ask questions to avoid looking ignorant, don’t admit mistakes to avoid appearing incompetent, don’t offer ideas to avoid seeming intrusive, and don’t challenge the status quo to avoid looking negative.

If a junior developer is unwilling to ask a senior why something was done or offer an alternative solution then the benefits of emergent architecture can be lost. If anyone on a team is unwilling to admit they were wrong. Or someone assigns blame to people on the team because they believe the work is an execution problem instead of a learning problem, then the architecture can go from a well curated system to a meandering or static design. For a team to guide an architecture there needs to be trust with in the team and a high level of communication.

Where can you find a better environment for holding trust and creating high bandwidth communication than mob programming? The team needs to discuss major architectural changes, and people on the team need to value each other’s opinions to ratify the changes. The beauty of working together on the same thing at the same time on the same computer is the team experiences the same pain. As an architecture becomes painful to work with because of a scope decision or an inherited legacy code base, the team together has the best context on why and when architecture should change. So given a safe environment, with a focus on technical excellence and bandwidth for learning, a team can reach that ideal state of continuous delivery through vertical slicing and high agility.

Finally, I want to directly address the difficulty in emergent design that I have personally experienced. The areas where I have seen the benefits fall away are when the requirements I mentioned in this post are missing.

When there has been an entire mob that lacks the technical knowledge collectively to properly architect a solution (i.e. Normalization, cohesion, coupling etc..) there have been expensive learning events which could have been avoided through technical mentorship on a mob.

I have also experienced technical decisions made in a team with low psychological safety. Impression management can be catastrophic to a project timeline. Developers who will not acknowledge their own fallibility can be particularly damaging.

Earlier in my career before mob programming I have worked on teams that were too afraid to change the architecture and instead made dangerous patches to the architecture simply because there was no technical safety. Errors modifying the architecture meant rolling back in source control in the best case. Worst case meant the problem was found in testing 3 months or more later.

Lastly, in multi mob teams I believe this becomes harder because the shared context of architectural pain can be deluded or lost when only a fraction of the team understands currently why the change needs to happen. As eluded to by Thomas Desmond the more mobs you add the more the shared context has a seeming less significant impact. This means that a change that makes a lot of sense to one mob may seem like a painful refactoring to another even though all mobs involved would benefit in the end.

Emergent Architecture is crucial to agility, continuous delivery, vertical slicing, and effective use of development time. The path we found there has been through promoting an environment of psychological and technical safety, as well as honing our technical skills to the point of excellence. Mob programming to great effect has helped create a level of transparency and safety that helps the team communicate and make decisions together.

As always, questions usually become full blogs, so please ask away!