Oddly Influenced

Welcome to oddly influenced, a podcast about how people have applied ideas from *outside* software *to* software. A mini-episode: What does Galison mean by “tradition”?

How do you know if *you’re* part of a tradition? In /Image and Logic/, Galison says traditions depend on the continuity over time of three things: skills and technology, people, and standards of evidence.

I’ll start with the continuity of skills and technology, using an interesting example from the Logic tradition of particle physics.

Radar works by bouncing microwaves off of distant objects. However, the radar operator is typically only interested in moving objects (like enemy airplanes). In the early years of World War II, the stationary objects occupied too much of the operator’s attention. It was hard to see the moving objects against the background.

So people invented the “delay line”. That was a physical device that would, roughly speaking, contain a snapshot of the previous radar image long enough for the next image to bounce back. Then the old image could be electronically subtracted from the new, eliminating what stayed constant. So moving objects would stand out.

The physical mechanism was a pulsing crystal that propagated a wave through mercury, relatively slowly, until it reached another crystal that would decode the signal. After the war, that same technology was used to build the very first computer memories. (You could store data indefinitely by routing the signal from the end of the line back to the beginning.)

People quickly invented variant delay lines that used different, more tractable materials. One transmitted an acoustic signal down a nickel wire. That technology was adopted by particle physicists. I’m not clear about the details, but I think it worked something like this:

A geiger counter counts a spark created by a particle. That counting happens immediately.

Meanwhile, the spark can cause a vibration at some point in a delay line. That vibration travels down the wire to the detector at the end. The time between the immediate detection and the delay line detection lets you calculate where the spark hit on the wire. Whereas before the logic tradition (see episode 8) could only count, now it could locate the position in one dimension – catching up a bit on the image tradition, which worked in three dimensions.

Now experimenters could start to think of a grid of delay lines to expand the idea into two dimensions. This approach kept being worked on and worked on and worked on, over a period of 40 years, in ever more complex detectors, until that tradition culminated in the Time Projection Chamber, which used a wildly different implementation that could draw three-dimensional particle tracks. But the required skills and technology could be traced back to endless incremental improvements to World War II delay lines.

I think that’s cool.

That’s an example of a successful long-term lineage of skills and technology. But the situation isn’t always so rosy. For example, cloud chambers required extremely clean optical-quality glass walls. Early bubble chamber workers spent a lot of effort building similarly pristine chambers before people noticed that it was not in fact required. Bubble chambers worked fine with dirty metal walls. That reminds me of a tweet by “@made_in_cosmos”:

“traditions are like old codebases: half of it is critical infrastructure, and the other half are workarounds for ancient problems that no longer exist, and you can never tell which half is which”.

That is, you’re not *part* of a tradition until a lot of what you do, you do unquestioningly. You do it because that’s what people like you do.

That makes sense as a career strategy. A tradition contains enough old habits that the person who obsesses over them may never get around to doing anything new. I once read a foundations of mathematics book defending its topic against the apparently common opinion that studying things like “what is a valid proof?” just gets in the way of *actually doing math* – so foundations were something only mathematicians too old to be productive should care about.

(Please keep any comments about old programmers doing podcasts to yourself.)

All that suggests challenges to a tradition will typically be resisted, whether they come from the outside or from particularly pigheaded insiders who decide to go the revolutionary route.

Resistance to change is a problem when a tradition is too strong. But, except for scattered exceptions, I don’t think that’s much of an issue for us. I’ll worry about traditions being too strong once we *have some*.

Technology exists as hardware (or something similarly concrete). In theory, you can pick up an instruction manual, learn the technology, and use it – learning the related skills from scratch. But that’s really hard. In practice, skills get passed down by people. People are the carriers of tradition.

That is, it *matters* that so many Haskell people have been working on it for approximately ever. They have established a solid tradition.

Moreover, because Haskell is so tied into academia, its programming subculture can piggyback on what’s called an academic genealogy. As wikipedia puts it, “An academic, or scientific, genealogy organizes a family tree of scientists and scholars according to mentoring relationships, often in the form of dissertation supervision relationships.” Such an inheritance is meaningful because it’s pretty common for a professor’s graduate students to do similar research – to carry on something of their mentor’s legacy or tradition.

Based on conversations with my wife, carrying on a particular person’s tradition is also very powerful in medicine. When she worked on the clinic floor, she did Dr. Nelson-style surgery because that’s who she trained under and who she looked up to. And guess what happened to the veterinarians *she* trained? Dr. Nelson lives on.

The more applied sciences – like medicine – are capable of even stronger traditions because students are not just mentored by their dissertation supervisor but by postdocs and – perhaps especially – by long-time laboratory technicians. There are lots of veterinarians today who can be called, in part, Arnold-style veterinarians because they learned so much from long-time vet tech Connie Arnold.

All this sure beats senior programmers quote “mentoring” their juniors by commenting on pull requests.

The early days of Agile did seem to have a similar impulse toward continuity and lineage. Many of the people who codified Agile had been heavily involved in the patterns movement, and had, before then, been “knights of the square bracket” – that is, Smalltalk enthusiasts. These people were “doing sort of the same thing” for as long as Simon Peyton-Jones has been working on the Glasgow Haskell Compiler and so helping to establish the Haskell tradition.

Ward Cunningham was one of the core Smalltalk to Patterns to Agile people. And there were people who aspired to be Ward Cunningham - style programmers in the way that my wife aspired to be a Dr. Nelson - style surgeon. Let me tell a story about that.

First, a bit of background. Among mathematicians, there was – and may still be, for all I know – a bit of folk culture called the Erdös number. Paul Erdös was a mathematician who basically spent his life wandering around the world, writing papers with other mathematicians. (I have a link to his biography in the show notes. Definitely an unusual man.) People started saying you have an “Erdös number” of 1 if you’d written a paper with Erdös. Your Erdös number was 2 if you’d written a paper with someone who’d written a paper with Erdös, and so on.

In the early 2000s, people started talking about their “Ward number”. It was 1 if you’d pair-programmed with Ward Cunningham, 2 if you’d pair-programmed with someone who’d pair-programmed with Ward, and so on. I want to claim that people cared about their Ward number exactly because they saw him as an exemplar of a particular approach to programming (the Extreme Programming tradition). Having a Ward number signifies both to yourself and to others that you want to be within his tradition.

(I can’t resist saying that my Ward number is 1.)

As GeePaw Hill frequently points out, our field has grown so fast that basically everyone is a novice. I think that means we’re unable for now to establish anything like a broad tradition. Perhaps the best that can be done is to establish team traditions by *working together* through pair or ensemble programming. And by *keeping* teams together. My hunch is that frequent movement of people among teams, and companies, will do more to prevent any particular team from settling on a local tradition than it will act to spread a local tradition more broadly.

Moving on to standards of evidence.

Galison presents standards of evidence as an elaborate network of interlocking habits that serve as constraints on what you can believe. Here’s a longish quote about how hard it is for a theorist to try to incorporate a new experimental result into a theory.

“You try adding a minus sign to a term – but cannot because the theory then violates parity; you try adding a term with more particles in it – forbidden because the theory now is nonrenormalizable and so demands an infinite number of parameters; you try leaving a particle out of the theory – now the law has uninterpretable probabilities; you subtract a different term – all your particles vanish into the vacuum; you split a term in two – now charge is not conserved; and you still have to satisfy conservation laws of angular momentum, linear momentum, energy, lepton number, and baryon number. Such constraints do not all issue axiomatically from a single, governing theory. Rather they are the sum total of a myriad of interpenetrating commitments of practice: Some, such as the conservation of energy, are over a century old. Others, such as the conservation of parity, survived for a very long time before being discarded. And yet others, such as the demand for naturalness […] have their origin in more recent memory. […T]aken together, the superposition of such constraints makes some phenomena virtually impossible to posit, and others (such as black holes) almost impossible to avoid.”

end quote

What’s the result of those constraints? Here’s another quote:

“In the 1970s, two experimental collaborations from atomic physics used reactions in bismuth to argue that the much-celebrated neutral currents of Weinberg, Salam, and Glashow did not exist. In fairly short order, theorists began treating the experimental results as mistakes even without an account of the details [why].”

The experimental results couldn’t be accommodated. They broke so many constraints, violated so much of the tradition, that the theorists had no choice but to reject them, not unless they were willing to risk a revolution.

I’m the sort of person who’s always been described as “having a problem with authority”, so I’m always happy to follow and amplify revolutionaries who reject constraints like “tests should be automated or, if that’s impossible, manual testers should follow a strict script” or “total cost of change will be huge unless you get the requirements correct up front.”

Galison’s book suggests two things to people like me:

1. Focus your attention on people already prone to your point of view. Don’t waste your time arguing with people intent on defending the tradition you’re trying to overthrow. Your aim should be to split the tradition, defend your half, and keep it growing – not to defeat some enemy.

2. Engage with people outside your tradition. If you’re a renegade theorist physicist, work especially closely with experimentalists who are happily chugging along in their own tradition. This advice helps me understand a fantastic blunder I made in 2003. I was involved with two renegade traditions then: context-driven testing and Agile. I thought they naturally fit together, like peanut butter and chocolate. So I organized a week-long workshop called “Agile Fusion”. It was a disaster, and I now think a problem was trying to mix two groups with different sorts of, um, Rages Against Two Different Machines. Agile did successfully incorporate testers, mostly. But that happened not because of us context-driven testers. It happened because of already-started collaborations with people who wanted to *do* testing rather than *fix* testing. Witness Lisa Crispin and Janet Gregory’s work, then and now.

As Lisa Crispin responded when I asked if it was OK to make the above claim, quote “For me, XP was a revelation of how we could build quality in together. All about people & testing. Nobody was asking for “testers”, but I knew we should be part of the team.” I admire her attitude: the person from a different tradition pitching in to help a tradition still finding its feet.

Thank you for listening.