Conversation

Notices

1. Embed this notice
   Patricia Aas (patricia@social.vivaldi.net)'s status on Wednesday, 14-May-2025 04:43:06 JST Patricia Aas

   15/ The fallacy Affirming the Consequent has the form:

   If P, then Q.
   Q.
   Therefore, P.

   Would then be:

   If two groups can't effectively collaborate (P), they will create an interface (Q).

   They have created an interface (Q).

   Therefore they can't effectively collaborate (P).

   However, that's of course not true, there are a million different reasons why you would create an API, I would go so far as to claim that every single programmer creates interfaces in their own code, even when they are only "collaborating" with themselves. We call them many things, one word for them is: Abstractions.

   I also claim that a single programmer is peak communication efficiency when it comes to communicating with themselves, more than any other programmer would be with them.

   You have direct access to your own memory, you share style, preferences and have a common understanding of the system and it's requirements.

   • Embed this notice
     Patricia Aas (patricia@social.vivaldi.net)'s status on Wednesday, 14-May-2025 04:43:04 JST Patricia Aas

     in reply to

     20/ Which brings us to the problem with the Fundamental Assumptions:

     Assumption 1. The desired architecture is known
     Assumption 2. The desired architecture is optimal

     I question both of these, but probably 2 most of all.

     We learned a long time ago that upfront design makes bad systems. And these two assumptions are 100% upfront design.

     I will claim that we never KNOW which is the optimal architecture.

     We have an hypothesis for what is optimal for us, but there are (as opposed to what this book seems to assume) many more architectures than "monolith" and "micro services".

     I would even claim that most systems contain many architectures.

     Even the most basic CRUD system has a backend, frontend, data layer, data analysis, maybe a data lake, monitoring, CI/CD, maybe even some machine learning. All of which can be structured in many ways, and interface in many ways.

     Then we have embedded systems, browsers, calculator mobile apps, single player games, multiplayer online games, audio mixing applications, video editing software, compilers, operating systems etc etc.

   • Embed this notice
     Patricia Aas (patricia@social.vivaldi.net)'s status on Wednesday, 14-May-2025 04:43:04 JST Patricia Aas

     in reply to

     21/ This entire book hinges in my opinion on a handful of assumptions:

     A) There are two architectures: monolith and micro services
     B) Micro services are vastly superior
     C) That you can force an organization to create micro services by controlling the way people are allowed to communicate
     D) That such an organization will be efficient
     E) That such an organization will make good systems
     F) That such an organization will be a good place to work

     I question all of these assumptions.
     Or more directly, I disagree with all of these assumptions.

   • Embed this notice
     Patricia Aas (patricia@social.vivaldi.net)'s status on Wednesday, 14-May-2025 04:43:04 JST Patricia Aas

     in reply to

     22/ It’s also important to point out that Conway himself argued, in this paper, the one from which this law is derived, for a flexible organization that can adapt to changing design and geared towards collaboration.
     http://www.melconway.com/Home/Committees_Paper.html

   • Embed this notice
     Patricia Aas (patricia@social.vivaldi.net)'s status on Wednesday, 14-May-2025 04:43:05 JST Patricia Aas

     in reply to

     18/ I think the fundamental problem here is that Conways Law is descriptive and Inverse Conway Maneuver is normative.

     Conways Law says that this tends to be true, or more explicitly: It was a pattern Conway himself observed.

     Inverse Conway Maneuver is not an observation of actual teams producing actual software, it is a thought experiment mostly concerned with answering a question that has not been asked: How does a reorg affect architecture?

   • Embed this notice
     Patricia Aas (patricia@social.vivaldi.net)'s status on Wednesday, 14-May-2025 04:43:05 JST Patricia Aas

     in reply to

     19/ I find it extremely naive and lacking analysis, hiding decades of academic study of teams in what superficially mimics a logical conclusion, but in fact is extremely easy to refute: A single person can create both a monolith and a micro service architecture.

     Conways Law fundamentally only says that it is easier to collaborate with people we talk to, which is honestly only a revelation to people in tech.

     People who collaborate can create all kinds of architectures, and most of all: they can adapt to changing conditions.

   • Embed this notice
     Patricia Aas (patricia@social.vivaldi.net)'s status on Wednesday, 14-May-2025 04:43:06 JST Patricia Aas

     in reply to

     16/ Based on the above I will claim that Inverse Conway Maneuver is not a logical consequence of Conway's Law, but rather a logical fallacy.

     If it was necessary to shape organizational "communication structures" to produce the desired interfaces in the architecture, then a single team or a single person would not be able to produce such a system.

     Fundamental assumptions:

     Assumption 1. The desired architecture is known
     Assumption 2. The desired architecture is optimal

     Inverse Conway Maneuver:
     Assumption 3. The desired architecture can only be achieved by an organization with the same "communication structures" as the desired architecture.

     All of these assumptions are problematic, we'll get back to that later.

     Lets phrase it as a statement of logic in terms of Conways' idea of "communication structures":

     If you shape "communication structures" in your organization to reflect your desired architecture (P), then your system will inevitably have this same communication structure (Q).

     According to Modus Tollens:

     If P, then Q.
     Not Q.
     Therefore, not P.

     Where !Q is : The system does not reflect the communication structure

   • Embed this notice
     Patricia Aas (patricia@social.vivaldi.net)'s status on Wednesday, 14-May-2025 04:43:06 JST Patricia Aas

     in reply to

     17/ If there exists a team or person that can produce a system with an interface (for example an API or one or more collaborating micro services or even a layer of abstraction), then such a team or person would be a violation of Inverse Conway Maneuver, they have produced a system with "communication structures" that are not a reflection of their organizational "communication structure".

     Or if there exists a group of teams that build a system without interfaces, since such a thing does not exist we'll just call it a monolithic system. Then that is also a violation of such a statement.