There is a famous anecdote about Sinan, the architect: when he was building the Selimiye Mosque, a child pointed at the minarets and claimed one of them was leaning. Sinan reacted immediately, instructing the workers to attach ropes to the minaret and pull until the child confirmed the minaret was now straight. The minaret wasn’t actually leaning, and the workers didn’t change anything by pulling. The perception of the minarets was at risk, and Sinan addressed that.
Continue reading Communication is crucial to architectureTag Archives: communication
Poor man’s active listening: is it good or bad?
“Did you understand?” We all know that we can never trust the answer “yes” to this question, yet we fall into this trap unavoidably. Most often due to lack of time or patience.
Ideally, we should get a summary from the listener of his understanding in his own words, much like a checksum, so you are sure the message gets across. Or when we are listening, we should summarize what we just heard and aim to get an acknowledge to that. This is called active listening (or reflective listening on Wikipedia).
Yet sometimes the time is tight, we just feel lazy to execute this method, or our communication partner is not willing to prolong the conversation. In this case, I find an easy solution is to ask if it’s a good or bad thing. An example:
Continue reading Poor man’s active listening: is it good or bad?Conway’s Law, communication & architecture
When designing an architecture, one should respect Conway’s law. Respecting it does not mean reversing the BAPO model, and deriving the architecture from the organization. Rather it means taking the organization and its adaptability into account when designing. Even if the architecture is perfectly aligned with business, but the architect doesn’t have the means to influence the process and the organization accordingly, there will be architectural drift caused by the mismatch with the organization.
And when we can, we try to define teams according to the architecture. Often with the premise of reducing the communication overhead in the organization, we try to break down the system into cohesive subsystems and corresponding, ideally two-pizza-sized teams. The math behind is explained simply in The Mythical Man-Month that the number of necessary communication channels grows quadratically in relation to the team size.
But, communication is essential in software development. Why do we want to reduce it?
Continue reading Conway’s Law, communication & architecture