Notes for week 16 of 2021
In terms of output, a slower week again. It’s my favorite outdoor weather here and it’s hard for me to resist the call.
- I’ve walked 28 km and rode 101 km. I’ve been active for 12.3 hours during 14 activities. This week’s max speed was 57.2 km/h.
- A reminder that in the US, your butt belongs to your employer 100% of the time
- New upgrade of MacOS associated ⌘E with „Use selection for find“, which broke my custom „Archive“ shortcut in a weird way. It gets fixed by removing the custom shortcut from system settings, restarting Mail.app, adding it again, and restarting again
- I am re-reading Lord of the Rings. The foreword talks at length about how this edition, published in 1993, should be less erratic than others as it was typed into the computer for the first time. LOTR movies started production 4 years later. There was some magic in the 90s.
- I accidentally published one of my notes prematurely, so I just went in and pushed the not-entirely-polished version of How To Talk To OAuth2 Server With Authorization Code Flow From The Console. Based on my Strava adventures.
- I was accidentally setting RSS headers on
- I’ve opted this blog out of Federated Learning of Cohorts. This is a good guide for various configurations
- I got unreasonably annoyed by a Firefox update that makes currently active tab really sticking out. It’s a small thing, but it really breaks my focus. I wonder whether I am starting to be conservative about UIs
Accelerate: Building and Scaling High-Performing Technology Organizations
The highly acclaimed and heavily recommended book that takes a scientific approach to a field I love. What’s not to like? Well, most of the book.
I really like what the authors are trying to do. I love the results since they are aligned with what I am already doing. I appreciate the effort. But the result does not pass my bullshit test.
The book is divided into two parts, ordered counterintuitively. The first one discusses the result of the research. The premise: authors dissected a large number of companies, applied statistical magic, and can tell what practices predict high-performance organizations.
Authors go at length to discuss the individual components, but I believe most people can just look at the „Overall Research Program“ diagram available in the Downloads section of the book. The overall results confirm common sense: it all starts with good leadership and without it, you are…stuck. While having the dependency tree dissected is mildly interesting, it doesn’t provide much value if you already know Lean practices. If you don’t, I don’t think you have enough explanations here and you should reach out to other books in the library.
One thing I learned there was Westrum’s typology of organizational culture. Westrum identifies three types: pathological, bureaucratic, and generative. If it feels like labeling „underperforming“, „mainstream“ and „overachievers“, yup, it is. The key insight is that those formed are based on how organizations process information. There is a nice summary table on page two of the paper. Still, it rubbed me wrong the whole way as it instills the „what’s good and what’s wrong“ language into the book, as opposed to looking for reasons and trade-offs.
I had one thing running in the back of my mind for the whole part one. „This is nice and dandy, but how have you addressed the self-reporting bias?“ While authors talk about their findings in a universal way, all of it is based on a survey filled by self-selected participants. Unless this is addressed, even if the statistical methods are correct, they only apply to the Lean echo chamber.
I was happy to find that this problem was recognized by the authors. I was not convinced about how it was resolved:
This project started with a desire to understand how to make technology great and how technology makes organizations better. Specifically, we wanted to investigate the new ways, methods, and paradigms that organizations were using to develop and deliver software with a focus on Agile and Lean processes that extended downstream from development and prioritized a culture of trust and information flow, with small cross-functional teams creating software. At the beginning of the project in 2014, this development and delivery methodology was widely known as „DevOps“ and so this was the term we used.
Our research design—a cross-sectional data collection for four years—recruited professionals and organizations familiar with the word DevOps (or at least willing to read an email or social media post with the word DevOps), which targeted our data collection accordingly. Any good research design defines a target population, and this was ours. (…)
(…) This targeted research design was a strength for our research. No research design can answer all questions, and all design decisions involve trade-offs. We did not collect data from professionals and organizations who were not familiar with the things like configuration management, infrastructure-as-code, and continuous integration. By not collecting data on this group, we miss a cohort that is likely performing even worse than our low performers. This means our comparisons are limited and we don’t discover the truly compelling and drastic transformations that are possible. (emphasis mine)
What? How do you know? Sure, I believe that as well, but I thought this whole book is about the scientific and evidence-based approach and verification.
To me, this breaks the whole premise of the book. The research intentionally omits high-performing organizations that are not using or are not interested in the Lean approach. This means all identified techniques for high-performers are only valid if you limit yourself to think within the Lean box.
The feeling of an echo chamber was reinforced by the case study chosen for the book. Of course, it’s ING Netherlands, the poster child of the Lean movement. By no means do I want to undermine their achievements, but if all success stories are based on a population of n=1, I am not convinced.
I am not sure to whom I’d recommend this book. If you are sold on the Lean approach, there is nothing new. If you are interested in Lean, this book will not teach you; look for something else (for software, I think Lean Startup is still a good start). It’s not an enjoyable read; the language hasn’t escaped its academic origin. Comparatively, even Phoenix Project is better writing.
I believe the only good audience is students writing a paper or thesis. This would be a gold-mine book for my own thesis a decade ago as it’s hard to find any data for this field. Unfortunately, the selection bias will make it a limited use even there.
Nicole Forsgren, Jez Humble, Gene Kim: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. Book site. Review based on Kindle edition, ISBN 978-194278362 Rating: 1/5.
I read Neverwhere a very long time ago, but it was a story that stuck with me. When I got a new edition as a present, I decided it’s time to go back. I also think I originally read a translation, but now I was ready to go enjoy the Original Gaiman English.
I am not sure whether I like the illustrated version a lot. Don’t get me wrong: they are done well, blend into the text superbly and fit the mood. But what I like about books is the art of omission. They allow me to collaborate with the author on the world-building, filling in the blanks the author left for me. Illustrations anchor me and limit this space. It is a bit like watching a movie before reading the book.
I believe what makes Gaiman so appealing is his use of mythos. London Below is so appealing because it draws on old things that are True. The whole book would be way shorter if the Truth wouldn’t hold. Favours are done and favors are owned. Debts are paid, even if it costs your life and even if you own it to someone who already died. The world is ruthless: nothing is done for free. If it is, well, you own a favor.
This makes Neverwhere resonate even if you don’t live in London. If you do, add a star: the images are more vivid if you know places. But even without, Neverwhere makes an enjoyable hero story.
Door will open the London for you.
Neil Gaiman: Neverwhere, The Author’s Preferred Text. Illustrated by Chris Riddell. ISBN 9781472234353 Rating: 4/5. Book website.
Recommended Readings From This Week
- 35 Principles for 35 Years: Some food for thought
- Double (IEEE754 Double precision 64-bit): Good visualization of how doubles work inside computer memory
- Deep Learning State of the Art (2020) | MIT Deep Learning Series: Useful overview for people not in the trenches
- Telling people to delete Facebook won’t fix the internet: The blame-shift is the oldest company trick
- How Not To Get Fired As A CTO: Good interview tips.
- Why do we pay sales commissions?: If you think all politicians are crooks, they will be. Same for salespeople
Published in Notes and tagged Weekly Notes