The very first episode of Oddly Influenced was about Star & Griesemer's idea of "boundary objects." That's proven to be a fairly hard concept to pin down, and I did at best an average job. Fortunately, I'm rereading Étienne Wenger's book Communities of Practice to prepare for episode 21, and he adds some useful words. A difficulty with the boundary object idea is that it's tied up with "meaning," not the most self-explanatory word.
This is an addendum to podcast episode 20 on Orr's Talking About Machines, about copier repair technicians. Orr uses Levi-Strauss's idea of "bricolage" as a way of talking about what makes a good copier repair tech. Broadly, bricolage is the process of rummaging through a whole bunch of things (ideas, experience, tools) you've collected to see which might help you reach a goal, then assembling the pieces you've found (possibly tweaked) to actually reach the goal.
Many years ago, I learned to fly gliders (sailplanes, airplanes but without the complicated engine bits). I learned two contradictory lessons that have stayed with me. Don’t just do something, sit there Since gliders don’t have engines, something has to pull them into the air. Probably the most common way is to attach a tow rope from the front of the glider to the rear of a single engine airplane. The two aircraft take off together, with the tow plane pulling the engine to, say, 2000 feet.
@Migueldeicaza pointed to an article titled "The rise and fall of peer review", which argues that the current method of scientific peer review is relatively recent (it only became common in the 1960s) and hasn't worked out. The problems are fairly well-known: peer review takes a long time, greatly delaying the publication of useful results; reviewers don't catch the really important problem because they don't look closely at the underlying data, the statistical methods, and so on; some reviewers (stereotypically "
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.