Some authors have recently returned to my 1994 pattern language dubbed EPISODES. This pattern language has been recognized as a founding work in the history of Extreme Programming (XP) and Agile. So an inquiry into roots of the now accepted and consequently diluted practices might be valuable for those who want to know more about how Agile came to be.
As Thompson Morrison writes, "While the core value of the sprint is primarily externally defined, the core value of these episodes are internally defined, as an essential part of the learning journey of the team." They create, what he called, an Episodic Flow.
When John Bywater introduced Drops he shared that it was "inspired by the turn to eventing in software development, and encouraged both by the modern, event-oriented, process metaphysics of Alfred North Whitehead, and by Christopher Alexander's pattern language technique for describing patterns of events, exampled most brilliantly in Ward Cunningham's EPISODES."
A recent discussion in a chat room initiated by John gave me an opportunity to reflect on the circumstances of its creation. As Kent Beck once remarked, "many of the ideas of XP first found expressions in Episodes."
Background
I am as old as general-purpose computing since EDSAC and I appeared in the same year. (EDSAC was the first computer build without a specific purpose in mind. That is, it was of general-purpose.) I learned of computing in my teens and was twice that when I encountered the refined abstractions of Smalltalk and set out to understand their full consequences. At that point in my 30s I had half a lifetime of experience to draw upon.
Although Smalltalk organized its worlds around things – objects – much more fundamentally it was about the exploration of things, things of the imagination. It was itself born over a decade within the Learning Research Group at PARC in the 70s.
Kent and I had already devoted months exploring with Smalltalk. We built things to see if we could and then played with them to see what else they had to teach us. We sought to explain the methods that had evolved. We had some advantage here since we had done must of that exploration together and had articulated much of what we discovered making up new words if they were needed.
We kept pushing on pattern language which seemed powerful enough to describe our experiences in their most essential. By the time I wrote EPISODES I was several years into commercial software development with the latitude to work the way Kent and I had and see how it applied within a more directed environment. The objects we had by then constructed were interesting but not quite as interesting as how we moved through a complex domain, learning and then turning what we learned into durable value to be sold.
Insight
I wrote EPISODES in an abbreviated style. I had lots to say all based on recent experience. I quit halfway through and dubbed my work Part 1. I blamed this on the page count limit but it was really me getting tired.
I have recently gone back to read this paper just to make sure I said something as profound as what others are now reading into it. I did say it. And it might not have been said more clearly if I wrote Part 2.
At some point during the writing process, I stopped and asked myself, what one word describes this bundle of experience. I chose "episodes". I thought that my choice needed some explanation:
We are particularly interested in the sequence of mental states that lead to important decisions. We call the sequence an episode.
I could have called the paper "A Method for the Incremental Discovery and Maintenance of Business Objects." I had pointed out earlier that year that one rarely gets the names of their objects right and would be wise to rename them once they understood what they did. I chose EPISODES because I thought it might fit into a system of names. See wiki.