Ok, I’m sorry, I’m going to ruffle feathers here but… I’m trying to read some newer development process books and… oh my… even super popular ones are so immensely long winded and unconvincing in their dogmatic argumentation: this is bad, this is good, because I said so that’s why.
Recent examples that I’m struggling to finish: “Team Topologies” and “Data Mesh” - I mean they might be great but I’m getting strong “this should’ve been a blogpost” feels.
The worst part of Agile and Lean etc has been the wave of folks earning their living telling you confidently how to build while they themselves have barely ever shipped anything.
I mean… get that money I guess… but it sucks to be continuously refactored *cough* reorged because someone who can’t build read the executive summary of a book by someone who can’t build.
Jeez this was hash, Patricia. Eat your dinner.
I’m dying. “If people are talking with each other of their own accord that’s a bad sign because…” I don’t even know.
Dear lord are they reinventing silos but with fancy words?
I ate. And it didn’t help.
“Monolith bad!” “Micro services good!” “People talking bad! People talking is basically a MONOLITH 👻”
I think maybe I shouldn’t be allowed to read.
Seriously so far the good parts of Team Topologies are the parts they have taken from other peoples work.
I suddenly remembered the Agile Coach I pissed off a few years ago that angrily told me he had actually been a dev for two years fifteen years ago!
Omg these people are ridiculously condescending
Help. Why do folks love this book?
Please. It is a mashup of 10 other pieces of original work.
If only the mashup made sense. But it doesn’t.
I can’t. “This is how you simplify things for these silly dev folks who struggle to understand even basic stuff.”
“How to break down large domains”
If you think that there is a Perfect Org Breakdown for all the things I believe you don’t know anything about anything.
Fuck it. I will refuse to listen to anyone saying “team cognitive load” to my face.
I posit that this book is result of a bunch of folks who are personally struggling to understand how anything is ever built by anyone.
“Here is example number four of a team who struggled to keep up with requests after a lot of people started to use, love and depend on the thing the team had built”
“They are struggling because… actually… they are extremely dysfunctional and not actually… extremely successful”
Grrrrr 😡
I’m sure they TALKED WITH THEIR USERS ☠️ fuck that monolith behavior.
You should break them up right now. This is the death of software.
Ok, they are ripping off everyone, but they don’t even understand the stuff they ripped off.
“Here is someone else saying you shouldn’t introduce bottle necks. WELL ACTUALLY, that means PEOPLE SHOULDN’T TALK WITH EACH OTHER”
I can’t. Sometimes they stumble into something I agree with and then five seconds later “ah, yes, someone else’s idea”
They are not even internally consistent because they’re ripping off everyone else: you should have stable long running teams, but you should definitely split up the teams because of this fucking number someone else made up which is unfortunately completely different than this other number someone else came up with which you should definitely also use. Except it is an order of magnitude bigger. So. Do that. Right? Get it?? COGNITIVE LOAD!!!
Ok. That’s it. If you say Hot Desking is Good Actually… no.
This book is made for cherry picking quotes to support whatever you want. Just make sure no one else can be bothered to read it.
I think maybe there isn’t a single thought that anyone has ever written about in tech that they haven’t taken into this book. But the only times they make logical sense is when they’re literally quoting other people’s text.
Seriously. I am going to become a software process Luddite after reading this. “Google big, Google scale, Google smart” “You not smart” “Make silos and don’t talk to anyone” “make API call to George, but not too often!”
Dear lord they have now said that Netflix-Spotify-Nokia-Ericsson-Google-dhh-Amazon (and basically everyone else) do stuff and you should do stuff too. But don’t bother the pretty little heads of your cognitively struggling/overloaded teams of some size between 5 and 50 or something.
Breakdown silos by breaking up your long running teams! And… break up the team building database software because that’s basic stuff probably.
We are not allowed to use the words Software Engineering before we stop reading these books.
I will never be allowed to work with any Agile Coach ever
I’m sure they TALKED WITH THEIR USERS ☠️ fuck that monolith behavior.
This is completely true and also the most devastating burn: this book would’ve been an order of magnitude better if it was written by a large language model.
This is basically just re-making the most dysfunctional orgs pre-DevOps but now with CLOUD! And Ops goes under 5 different names because the ideas have been taken from at least 5 other places. And for goodness sake: don’t talk, but also talk serendipitously while hot desking! And do stuff like Amazon and Google and Nokia and Spotify and… all of the orgs that have ever written about whatever they do.
@Patricia thank you for this thread.
Yeah. Everyone has been reinventing Gilbreth for a century.
Patricia Aas
(moved)Galbinus Caeli 🌯