Patricia Aas
1/ Alright, I'm back with what I assume will be a week long rage thread about a book I hate. It's really not important for current events in any way, but I signed up for a talk about it in the before-times.
So mute this, it's absolutely not interesting unless your org is actually reorging based on this book.
I'd suggest not to argue with me in this thread, I've bought the book twice and I hate it. I have paid my dues, and I am already pissed that Past Patricia made me read it again.
Patricia Aas
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
Patricia Aas
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.
Patricia Aas
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.
Patricia Aas
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).
Patricia Aas
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.
Patricia Aas
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.
Patricia Aas
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.
Patricia Aas
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
Patricia Aas
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.
Patricia Aas
3/ Last time I yelled at this book
https://social.vivaldi.net/@Patricia/112704847971770579
Patricia Aas
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.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.