Skip to content

Instantly share code, notes, and snippets.

@marick
Last active May 28, 2019 14:27
Show Gist options
  • Save marick/86677f36657b576981b0ac291a0f4ac3 to your computer and use it in GitHub Desktop.
Save marick/86677f36657b576981b0ac291a0f4ac3 to your computer and use it in GitHub Desktop.

A proposal to improve the speed at which reliable knowledge about software development is created

Extracted from a talk at NewCrafts Paris 2019, titled "Learning From How Science and Philosophy Progress".

Contents

  • Interaction rituals, the scene, and scenius
  • Science and reliable knowledge
  • Software and reliable knowledge
  • Scenes have places
  • "Frankly, that sounds like a boring scene"
  • Materials and methods

This proposal is inspired by The Sociology of Philosophies: A Global Theory of Intellectual Change by Randall Collins, the later chapters of Theory and Reality: An Introduction to the Philosophy of Science by Peter Godfrey-Smith, and by accounts of punk rock. (I was a listener, not a participant.)

I wrote the talk hoping to find people who want to participate. Talk to me at @marick or marick@exampler.com.

Interaction Rituals, the Scene, and Scenius

In The Sociology of Philosophies, Collins places a great deal of emphasis on interaction rituals, defined as:

  1. Two or more people, physically assembled...
  2. ... who are focusing their attention on the same object or action – and know that the others are doing the same1,
  3. ... and who are sharing a common mood or emotion.

Some typical examples would be worshippers at a religious service, fans gathered in a bar watching a game of the World Cup, or people pair- or mob-programming. (That accounts for the difference in the feel of pairing or mobbing: an interaction ritual is different than solo work.)

Collins claims that the fundamental interaction ritual for intellectuals is the conference talk (or similar gathering) in which an audience is focused on evaluating the claims of one or more speakers2.

In his book, Collins builds a detailed theory of what scholars get from such intellectual rituals (such as emotional energy, direction for their work, a sense of where the field is going, and which ideas have the best chance of yielding rewards) and how they take all that back to their day-to-day work, which – as scholars – is to write down ideas as part of a slower-paced and mostly-remote conversation. For this essay, I'm going to use a different term: the scene, something that is usually applied to musical scenes like "the punk rock scene of 1976-1978" but that I think captures nicely a simplified form of what Collins is talking about. In this essay, I'll be referring to intellectual scenes like "the agile development scene of ~1999-2003").

I think of a scene as being an iterated intellectual ritual of a special sort:

  1. The scene requires people, most of whom know who else is in the scene.

  2. It requires a consuming focus of attention – like the music that was not yet called punk in 1976 or the development style that was not yet called Agile in 1999.

  3. That focus of attention is rapidly growing and changing, moving from strength to strength. That causes the people in the scene to have the thrill of being part of a collective movement. As Mary Harron puts it in the punk oral history Please Kill Me:

    My heart would be racing every time I walked [to CBGB's, one of the two key clubs in the New York City punk scene]. And then the doors would open and I'd be there. I was so excited every night I went. Everything was new, and it was so exciting because I knew I was walking into the future.

The musician Brian Eno – who has been part of more than one scene – has coined a word for what results from a scene:

Scenius stands for the intelligence and the intuition of a whole cultural scene. It is the communal form of the concept of the genius.

Individuals immersed in a scenius will blossom and produce their best work. When buoyed by scenius, you act like genius. Your like-minded peers and the entire environment inspire you.

The idea of scenius declares that we don't need to wait for lone geniuses to save us. We non-geniuses can help create a scene whose scenius will produce reliable knowledge faster.

This particular essay proposes one specific way of fostering a new software development scene.

Science and reliable knowledge

In 1848, Lord Kelvin published results showing a value for the lower bound of temperature, now called absolute zero on the Kelvin scale. That bound was determined from experimental results relating temperature to volume and pressure. Plotting temperature vs. volume for each of three pressure values shows the three resulting lines converging on a single point: absolute zero.

Kelvin was fond of measurement. He famously wrote:

When you cannot measure [what you are speaking about], when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind.

I bring up Kelvin because Charles Darwin was at the same time in the rural village of Down, not far from London, writing two exhaustive volumes on barnacles: one on living barnacles, one on the fossil barnacles of England. And I do mean exhaustive. You can look for yourself(PDF): it's page after page of careful descriptions of individual genera and species of barnacles, containing pulse-pounding sentences like these:

[The] carina [is] always very narrow and curved, concave within, often carinated and barbed exteriorly; it extends upward between the terga for one half or two thirds of their length: at the lower extremity it extends (with the exception of L. fascicularis) in a small fork (Pl. I, fig. 1, a, b) rectangularly inflected and embedded in the membrane, beneath the basal margin of the scuta.

There are not many numbers in Darwin's books, but there are many detailed pictures. If, as the physicist Rutherford said: "All science is either physics or stamp collecting", Darwin may have been the most obsessive stamp collector of all.

And yet. Darwin was not just collecting details. As one commentator writes:

Darwin's study of cirripedes [barnacles] […] was a highly theoretical work that addressed several problems at the forefront of contemporary natural history.

My gloss is that natural history (biology) was facing the huge problem of how to classify the overwhelming variety of nature and to describe the relationships between categories. Like: how to know which species are most similar to each other? There were theories about how to solve this problem, and Darwin was exposing those theories to experience by using them on real-world data. (I'll explain the emphasis shortly.)

Besides producing a catalog of immediate and lasting value, Darwin's books did two other things:

  1. They earned him enormous respect amongst his peers, respect that caused them to take his later explanation of the mechanism behind evolution very seriously. They knew he sweated the details. (I like to think of him as having the same credibility as a software architect who's also known to also be a legendary coder.)
  2. The categorization provided supporting evidence for his later theory.

I think that's a wonderful story of science. Theories are tested against data. The results provide motivation for new theory. Theory and evidence interact cyclically. It is certainly not, contra Kelvin, a "meager and unsatisfactory" understanding. Darwin was precise, though not numerical, and that was entirely sufficient to create reliable knowledge.

What's happening here? Different sciences have different subjects and, therefore, they have different ways of producing reliable knowledge. Science does not operate by "one weird trick", much less one specific weird trick that applies to all the sciences. It operates by many tricks, and the different tricks have different specifics in the different sciences. That's why I emphasized "exposing theory to experience" above. That phrase encompasses experimental science of the familiar sort (create a hypothesis; make a prediction; test it via experiment), Darwin's work on evolution, astronomical observations, and so on.

Software and reliable knowledge

We can study software development in the conventional, numerical way. For example, people can and do create controlled experiments to test hypotheses about pair programming or test-driven design. (Although external validity is a big problem.) Or hypotheses can be tested by making queries against Github's immense database of open source projects.

I think that's all fine, but we should also use the Darwinian "collect stamps, categorize, and generalize" approach. For that purpose, I think we should make use of our equivalent of Darwin's barnacles: experience reports.

We are awash in recorded talks and blog posts of two kinds:

  1. "We tried technique X for time T and we have concluded Y." Especially when a new technique – like mob programming – hits the scene, you see a lot of these.
  2. "We are a company/project you've heard of and we do X this way." For example, the way the Rust language project handles continuous integration is very interesting.

All of these experience reports describe a particular version or species of X, but the descriptions are very rarely at the level of detail needed for reliable knowledge. I propose to start our new scene by having non-authors (founding members of our fledgling scene) take descriptions of X's and improve them by contacting the authors and getting them to say what was not written down or recorded.

An easy way to think of this is as writing commentaries about existing talks or writeups, commentaries that focus on careful descriptions of context. Context is important because the customers for such writeups are typically people who should be wondering if X (or the speaker's variant of X) is something they should try. That's really hard without having the information to match the speaker's context with one's own3.

I think of such descriptions as coming in two kinds, following an idea of the philosopher Gilbert Ryle:

  • thin descriptions: These are the objective properties readily available to an external observer: the number of PRs per week, the number of HTTP requests per second, the average time between when a PR is observed and when it's included in the nightly build, etc.

    Ryle's example of thin description is three boys "rapidly contracting their right eyelids".

  • thick descriptions: People, unlike electrons or barnacles, attach meaning to objective properties, and it's hard to make useful sense of objective properties without understanding that meaning. For example, I was once talking to someone whose strategy for handling pull requests made absolutely no sense to me. It was only when he said that the purpose of his strategy was to accumulate evidence justifying ejecting "sociopaths" from his open source project that its objective properties stopped seeming random. He and I simply attach different meanings to the idea of "pull request". (See Geertz's The Interpretation of Cultures for the use of thick description in anthropology, a use very relevant to how we might describe context.)

    Ryle extends the "rapidly contracting" thin description by noting that one boy has a tic that makes the contraction involuntary, another is winking to signal a friend, and a third is winking to make fun of the first boy. The different meanings matter, as demonstrated by what happens if one of the meanings is misunderstood.

(As a secondary goal, I hope such commentaries – because they're being made by members of a single scene – will do a better job with vocabulary. Even if we can't promote the use of a single word or phrase – rather than eight – for a single concept, we can work on the more serious problem of a single phrase being used for eight different concepts. Terms like "technical debt", "continuous integration", and "integration test" should not be used without at least a few sentences explaining which variant is meant.)

Sound dull? Read on!

Scenes have places

Since we humans are beings who move in three dimensional space, we've very sensitive to place. We're especially on the lookout for places where we feel we belong. For example, both the New York and London punk scenes had places where punk happened: see the Mary Harron quote above. (Punk had places where it happened even before there was a word – "punk" – to describe what was happening.) Collins points out that philosophical "schools" (scenes) were also particularly associated with places. Platonism was associated with Plato's Academy. Epicureanism had the Garden. An important strain of medieval scholasticism was associated with the University of Paris.

And the early development of Agile happened in a metaphorical place: the original wiki. (Note, again, that the place came before the term. "Agile" was only coined in 2001, but the discussions happened well before that.)

I have registered http://libraryofcontext.org in the hopes that it will become the place where a scene happens. If this proposal takes off, I intend to make editing and writing commentaries, soliciting and editing survey papers4, and maintaining the site my full-time job.

"Frankly, all that sounds like a boring scene"

I suppose so, just as Darwin's work on barnacles sounds boring. But, once his work was done, the scene it contributed to (the early years of Darwinism) was plenty exciting. That's what I'm hoping for from the commentary work: that – sooner, rather than later – our commentaries also focus on discovering and describing charged concepts.

"Charged concept" is, roughly, my rebranding of an idea of Collins. An intellectual scene contains many interrelated ideas. Certain of them are specially powerful:

  • They attract people to them, the way static electricity attracts hair or bits of paper.
  • They provide those people with emotional energy, like the way a power outlet charges a phone.

Examples:

  • Darwin was energized by seeing how embryology could be used to better understand the relationships between species.
  • The Agile Manifesto can be seen as a list of four charged concepts. One that greatly interests me is "working software". In the early days of Agile, I remember that phrase always provoking a great deal of discussion at my consulting clients: what does that idea mean in our context? when does "done" happen? how can we, in our situation, produce smaller bits of working software faster? I'd argue that this charged concept fed powerfully into continuous integration and devops, and then into ideas like testing in production.
  • One of punk's charged concepts was D.I.Y. (Do It Yourself), the idea that you should try to avoid experts from outside the scene. You should create your own look and clothes. You should avoid recording studios in favor of cruder recording onto cassette tape masters. Cutting-edge music should be distributed as duplicated cassettes bought through the mail rather than pressed vinyl bought in a record shop. Information should be gotten from the photocopied-and-stapled zines of fellow scene members rather than from the music press. As with Agile, a great deal of power-to-act-in-the-world was generated from a single charged concept, to the point that (it seems to me) modern-day punk has built a completely independent world.

It is my hope that our scene will truly be created as commentary writers discover charged concepts that inspire people to experiment and develop them. Once there are again ideas that matter, with a place where the important work happens, a scene will develop and scenius will appear.

Materials and methods

I grant that there is little demand for information about context. It's no accident that "You're not Google" is a meme. It's common for people to read about how Rust does continuous integration and think, "We should do that!" without realizing the difference between a global project and their five-programmer company.

My solution to the problem is supply-side. Suppose that we successfully move to a world where blog posts (or commentaries on blog posts and videos) regularly describe the context in a way as clear – and whose importance is as clearly highlighted – as the Materials and Methods section of a scientific paper. (After all, a Materials and Methods section really does describe the context that lead to the reported results.) Won't that cause people to realize they should pay attention to the context?


1 I suspect Collins would be skeptical of videoconferences because it's hard to tell whether others are focusing on the same object or surreptitiously reading their email.

2 It may seem that the audience for a talk doesn't "share a common mood". But I can say, as an experienced speaker, that audiences often do – especially if the talk is going extremely well or extremely poorly.

3 I grant that many people don't think about context – that they'll happily ignore the differences between a global open source project and their five person proprietary project. I favor a supply-side solution, which I describe at the end of the essay.

4 My wife does research on dairy cattle. If she needs to know something about, say, protein in cattle nutrition, she can go to The Journal of Dairy Science and find an article on that topic, written by an acknowledged expert in it, describing the current state of knowledge. That there's nothing equivalent for, say, pair programming in 2019 is really sad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment