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?
First, we don’t want to reduce communication itself. We want to reduce the need for communication. It will kill your speed if you need to clarify a topic with five people from various teams and with differing schedules and goals.
Second, when communication is needed in the given architecture, by all means do it to the full extent. When you’re discussing something within your team or discussing a change in an interface between two teams, leave no stone unturned and no issue open. Even invest time on aligning on the future vision of the topic under discussion. A well-designed architecture will highlight the critical areas as explicit architectural artifacts such as inter-team interfaces, so when you are talking about them, you know you are not talking about trivia. And with a badly-designed architecture, you still need to discuss, just more, as the architecture does not offer the distinction between the details and the important aspects.
So the answer is not because we’d rather be talking to our computers than to other people. The answer is that the communication is the most valuable resource in software development and we should use it wisely.