Play Telephone with your Architecture Description
The game starts with a simple phrase.
I heard that Sally ate nine cooked crabs and a plate of shoestring potatoes but later decided that eating crabs was wrong.
You tell the next person, quietly so no one else can hear.
I heard that Sally ate nine cooked crabs with a plate of shoestringed potatoes and decided eating crabs is wrong.
And that person tells someone else.
Sally ate nine cooked crabs with shoestring potatoes and she thinks eating crabs is wrong.
Who tells someone else.
Sally ate nine cooked crabs with sho-shu potatoes and she tin cans wrong.
And in theory, the last person hears the same message as the first person.
Ally ate nine crooked crabs with shoo-shoo potatoes and something about tin cans singing songs.
But it almost never works out that way in practice.
That's the "Whisper Game" or "Telephone" as we called it growing up.
You play the same game on software projects, especially when using lightweight design descriptions such as the system metaphor or architecture haiku. These lightweight design descriptions are intended to be shared by way of an architecture oral history. They are supposed to be living representations of the design for the software system being built, passed directly from one developer to another.
While playing Telephone with your system's architecture doesn't initially sound like a great idea, it's actually a really good thing. Playing Telephone lets you know some important things about your team and the architecture of the system being built.
I heard that Sally ate nine cooked crabs and a plate of shoestring potatoes but later decided that eating crabs was wrong.
You tell the next person, quietly so no one else can hear.
I heard that Sally ate nine cooked crabs with a plate of shoestringed potatoes and decided eating crabs is wrong.
And that person tells someone else.
Sally ate nine cooked crabs with shoestring potatoes and she thinks eating crabs is wrong.
Who tells someone else.
Sally ate nine cooked crabs with sho-shu potatoes and she tin cans wrong.
And in theory, the last person hears the same message as the first person.
Ally ate nine crooked crabs with shoo-shoo potatoes and something about tin cans singing songs.
But it almost never works out that way in practice.
That's the "Whisper Game" or "Telephone" as we called it growing up.
You play the same game on software projects, especially when using lightweight design descriptions such as the system metaphor or architecture haiku. These lightweight design descriptions are intended to be shared by way of an architecture oral history. They are supposed to be living representations of the design for the software system being built, passed directly from one developer to another.
While playing Telephone with your system's architecture doesn't initially sound like a great idea, it's actually a really good thing. Playing Telephone lets you know some important things about your team and the architecture of the system being built.
- Is your team aligned? Ask any two teammates about a specific design decision. If you get two different answers then you know your team is not necessarily on the same page. A paper artifact can give the illusion of alignment while in reality the team may not all understand the architecture of the to be built system.
- Have you explored all options? Letting the design evolve as decisions are passed by word of mouth, from developer to developer, creates opportunities for exploring options. Each time a developer tells the story of how the design satisfies specific properties desired in the system is a chance for uncovering new and better design decisions. This is an effective way to challenge assumptions and overcome bias when only a few individuals are directly involved in the design.
- Does the design stand up to scrutiny? Sometimes individuals hold back when the only option is to raise concerns in front of a large group. Bad design decisions that might go unchallenged in a larger group setting won't stand up to scrutiny among small groups of peers. Pairs and threesomes can easily play devil's advocate without feeling the fool. The result is a strong architecture that holds muster to real challenges, not just straw-man arguments.
- Is everyone learning from the design? A document can only describe a design in one way. Allowing the architecture design to be described through story telling lets the story teller adapt the story to best meet the needs of their audience. As a result, teammates learning about the design stand a better chance of learning and internalizing the key decisions they will be responsible for implementing.
- Does everyone own the design? A formal architecture description written on paper is really only owned by one or two people. Whether this ownership is official or not, the authors of the document will know the design the best and have the greatest vested interest in ensuring that the architecture is satisfied according to their design. Allowing the architecture design to be told and retold allows everyone to become an author. Now everyone has a vested interest in achieving the design - everyone is an architect.
Effectively communicating design decisions to a group of people is challenging. Writing things down certainly has its advantages. In reality, few individuals will take the time to read and really study an official architecture description anyway, so having a solid architecture oral history strategy is necessary for ensuring your team communicates and develops software as effectively as possible.
Yes, the design will evolve as it is communicated informally from person to person. But what is worse -- playing a game of Telephone with your architecture or playing with your architecture all by yourself?
Yes, the design will evolve as it is communicated informally from person to person. But what is worse -- playing a game of Telephone with your architecture or playing with your architecture all by yourself?
Comments
Post a Comment