In episode 41, I list five principles for reducing the cognitive load of Doing the Right Thing in a workplace. They involve shifting work onto the environment or the body. The rough idea is you get pushed into doing the right thing rather than having to decide to do it. The principles are: Favor direct control links from perception to action. Prefer composite values over atomic values. Avoid primitive obsession.
TLDR: This is a teaser for an upcoming Oddly Influenced episode. I hope it will interest people in being interviewed, and let them judge whether their experience maps onto – or comments on – the theory proposed in Michael P. Farrell’s 2001 book, Collaborative Circles. I’m looking especially for people involved in early Agile teams. I’m also hoping to do some interviews about Context-Driven Testing. ---- Collaborative Circles develops a theory of creative change, basing it on influential groups like the French Impressionists, the “Ultras” group of US first-wave feminists, the early psychoanalytic circle (specifically Freud and Fleiss), and so on.
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):