In response to "What got left out of software design patterns," Joel Tosi asked what Alexander got wrong in Notes on the Synthesis of Form. To answer, I think it worthwhile to quote Alexander's "Preface to the paperback edition" in full. All emphasis is in the original. Today, almost ten years after I wrote this book, one idea stands out clearly for me as the most important in the book: the idea of the diagrams.
For some years around the early ’90s, I was a regular attendee in Ralph Johnson’s software reading group. As such, I had a ringside seat to the development of design patterns. We read and discussed at least selections of the three seminal books by architect Christopher Alexander, Notes on the Synthesis of Form (which Ralph described, correctly I think, as a good description of the problem but the wrong solution), The Timeless Way of Building, and A Pattern Language: Towns, Buildings, Construction.
In Orr’s ethnography of photocopier repair techs (https://www.goodreads.com/book/show/20081966-talking-about-machines), he discusses how techs have to educate copier users to produce good bug reports - that is, descriptions of problems useful to the techs in diagnosing the underlying problem. I’m way out of date in software testing. Back in the day, software testers educated each other about writing good bug reports, and about how to escalate a minor bug into one that people feel compelled to fix.
In episode 17 and episode 18, I discuss Scott's Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed. Scott puts a lot of the blame on people's love of formalized systems (and the closely related concept of "legibility"). Fair enough. But I recently read this bit of text from a New Yorker interview with Cory Doctorow (Note: don't follow link if you're prone to seizures from flashing lights - pretty irresponsible, New Yorker):
So here's a question. As an XP person, my consulting leaned into saying people should for real try all of XP for a while before passing judgment. I think that was fairly common, back in the day. The Scrum approach was different in two ways. First, they were clever enough to realize they could get rich through the "certified Scrum Master" scam. I'm going to leave that aside. The other way is they didn't make teams do the hard technical stuff.