Notices by Patricia Aas (patricia@social.vivaldi.net)

13/ I also firmly believe that this is the nature of the fundamental problems that both agile and devops tried to tackle: How to better collaborate across organisational boundaries to create better systems faster.

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.

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

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.

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.

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?

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

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.

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.

4/ Fundamental "logical" conclusion of the book:

To *force* an organization to produce micro services (the epitome of software development) and not to risk a monolith (because those are the only two options that exist to man) one must create an organization that mimics micro services by eliminating as much cross team communication as humanly possible.

An organization that cannot communicate is the optimal organization.

Such an "optimal" organization consists of teams full of drones that do what what they're told, have no need to understand the broader context in which they exist, and that don't have the "cognitive overload" of integrating that context into their work. They will NOT (unless carefully orchestrated) communicate with anyone outside their bubble.

This is optimal because reasons.

It is a made up intellectual exercise that undermines decades of proven progress in software development, creating countless silos with all the associated problems. It is anti-agile, anti-devops, anti everything, and they don't even realize.

The rest of the book is other peoples work.

3/ Last time I yelled at this book
https://social.vivaldi.net/@Patricia/112704847971770579

2/ Reasons I hate the book:

1. It's wrong. If you follow whatever you manage to actually glean from this book your org will be less efficient and worse in basically every respect for absolutely no good reason.
2. It is really, really badly written.
3. The "logical" argument does not follow actual rules of logic (which I find surprisingly infuriating).
4. The parts that are not garbage are just regurgitation of other peoples thoughts.

Since people tell me that I'm supposed to say something nice too:

The graphical designer did a really great job, y'all should hire him, his name is Devon Smith.

The editors also did ok, the titles of parts, chapters etc almost seem to make sense.

7/ Starting from the beginning. The logical foundation from which all this springs: Part 1, chapter 1. Based around 2 ideas belonging to other people:

1. Conways Law, 1967 (which is an observation based on Mel Conways own experience) [1]

2. Inverse Conway Maneuver, 2015 (which is a made up thought experiment by James Lewis et al of Thoughtworks) [2]

[1]: https://en.wikipedia.org/wiki/Conway%27s_law
[2]: https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver

6/ FYI any «well actually» might result in a mute or a block because (read post 1) I’m not in the mood. I literally paid actual money for this book (twice) so I consider that to be all the dues I’m required to pay to say why I hate it.

5/ Any part of it you might agree with is someone elses idea. They are pulling in the works of literally dozens and dozens of other peoples original work. Some of it contradictory to each other.

Everything written about software dev in the past 25-45 years is in there somewhere.

That does not make it good.

That makes it unreadable.

9/ The solution in both agile and devops was one of closer collaboration.

The problem agile was trying to solve was one in which we tried to design everything up front and then had some sort of final delivery often years later, with few sync points in between, and often resulting in systems that might formally fulfil the requirements, but was often universally hated and often discarded or the basis of long legal battles.

The problem devops was trying to solve was imo a result of a culture clash between ops and dev where they are measured on fundamentally different metrics. Ops on stability and security, dev on feature development. One is awarded for keeping things the same, the other for changing things.

DevOps was therefore fundamentally a cultural project, and its success can be seen in the fact that most juniors have no idea what I'm talking about.

8/ Based on my own experience I can see how Conways Law can be plausible:

"[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?"

In many ways this was the problem that agile and devops tried to solve: that constraints on communication with our users and customers (agile) and between dev teams and ops teams (devops), created processes that resulted in inferior products and experiences (agile), and systems that where hard to maintain and change (devops).

10/ So to Inverse Conway Maneuver, this is a thought experiment, not based on experience. The basic idea is as follows:

"evolving your team and organizational structure to promote your desired architecture"

The reasoning here is that if we make an organization whose "communication structures" (to use Conways words) reflect the architecture we want to achieve then Conways Law will make this organization produce a system with this architecture.

Fundamentally: Re-org your organization to reflect the architecture you want.

12/ To scientifically prove Conways Law is difficult/impossible, we would need to formally define a whole host of things (including, most importantly, what "communication structures" are), and then we would need to find appropriate measurements and run a bunch of experiments. But for this entire thread I will assume that Conways Law describes a real mechanism in tech organisations: Two groups of people that do not collaborate, but create software that needs to collaborate, will tend to create at least two modules (at minimum one each) and create some form of communication between them: ones output is the others input (possibly bidirectional), for example an API or similar.

11/ This makes a bunch of fundamental assumptions that should be examined, first of all logic:

In formal logic we have "Modus ponens" [1] typically of a form like: "If it rains the grass gets wet, it has rained, therefore the grass is wet"

Another related concept is "Modus tollens" [2], which would then be: If it rains then the grass gets wet, the grass is not wet therefore it did not rain.

Associated with these is a common fallacy "Affirming the consequent" [3] which in this example would be: If it rains the grass gets wet, the grass is wet, therefore it has rained.

This fallacy is in this case easy to refute, we don't know why the grass is wet, it might have been sprinklers that got turned on.

[1]: https://en.wikipedia.org/wiki/Modus_ponens
[2]: https://en.wikipedia.org/wiki/Modus_tollens
[3]: https://en.wikipedia.org/wiki/Affirming_the_consequent