Organisms small and large learn by building a model of the world around them then testing that model against what they see and adjusting accordingly. We'll call this a learning loop. We identify three era in computing based on the nature of this loop and the kind of feedback learning that they support.
• The first era of interest is that of the read-eval-print loop. A big deal on timesharing.
• The second era I'll call the agile era was that of the iterative delivery loop. A big deal on desktop.
• The third era, that which we now study, is dominated by the incident recovery loop. A big deal in SaaS
# Delivery
Agile iterations deliver positive increments of both features and opportunity. If features are delivered while consuming opportunity soon the process breaks down, mired in debt.
Thompson Morrison has applied this loop abstracted into what he calls the agile mindset. For two years we dissected what this might mean and it has lead to this ground-breaking publication. See The Dayton Experiment
His interest has renewed my own so I have taken the time to chart in detail some of the often overlooked aspects of the agile loop. See XP Practice Network
# Loops
We learn by doing, over and over. We'll characterize software era by what we do and how much we learn. Karl Friston calls this "active inference" where the act is the key. He has shown that this applies over a very large range of systems. See Free Energy Principle
Computers have for a long time read input and printed output from whatever computation they were programmed to perform. But the REPL era began when parsing and evaluation of expressions was well enough understood to accept them as an interface through which one would interact with a computer.
Lisp pioneered the read-eval-print loop mechanism. APL made the syntax so compact that one line could often be the whole program. The Unix pipeline elevated this to assembling components. Now some form of read-eval-print loop exists in every debugger a programmer is likely to use.
Agile's iterative delivery allowed teams to learn from their customer as the customer learned from the team. A jointly held vocabulary allowed both to move through a creative space together. See Creative Challenge
In order to move relentlessly forward the team must create new opportunity at the same rate they deliver features. They will be effective to the degree they make good decisions regarding code cleanliness. Only shared experience in a particular codebase will lead to consensus. See XP and Normative Good
# Surprise
While one still turns to the REPL for questions about computer language and Agile iterations for questions of wants and needs, we now find our compounding of services to defy even the most careful analysis.
We compare this document's layers of process, technique and responsibility to Woods ten theorems and find one missing. See S4, Synchronization Required
Woods tells us that there is no omniscient point of view. Friston agrees. Todays systems will always surprise. And with each surprise, each incident, we have an opportunity to know more about what we built than we did yesterday. This is the incident-response loop that dominates our age and that is now being perfected. See Learning from Incidents
.
The event was presented at New Relic the week we became full remote and as a consequence the video is pretty good. My part starts at minute 49 of Chapter 4. I just watched it to be sure it was as I remembered. I come off rather folksy but 1.5x playback will fix that. There is a lot of me there and a lot of our future too.
video 