The Care and Feeding of Continuous Learning

The opening keynote at Pipeline Conference, the yearly, non-profit, continuous delivery conference that took place in London on March 20th, 2018 was given by Elisabeth Hendrickson. Her words to us are still resonating:

There is no failure, only learning – an awful lot of learning
– Elisabeth Hendrickson

Where is Testing in CD?
Continuous Delivery is about integrating code and moving to production continuously. It’s a core principle in Agile.
Some 15 years ago, the idea of moving code to production fourthnightly or weekly was pretty cool. Today, deploying to production daily, even several times a day is the norm. To make it happen:

• Projects avoid branches and releases
• Instead development and delivery is happening in a flow
• Regression testing is largely automated to support the flow
• Production is monitored to detect problems before they happen

The question is where that leaves the job of exploring a product to learn about it?
I found an answer in London, but not just at the conference.

Resilience in Continous Delivery

I went to Pipeline to hear what people have to say about CD. The speakers, of course, but people at the conference. The atmosphere was very positive and energized, but my own experience is that CD can sound a bit like the story about the fortune waiting at the end of the rainbow. CD carries huge benefits, but realizing them isn’t easy.
John Allspaw, author of “The Art of Capacity Planning”, former CIO of Etsy, and one of the originators of the DevOps movement, keynoted about Resilience Engineering: “It’s the story of the outage that didn’t happen”
It is fundamental to him that safety comes from people, not machines or products. He points out that everyone in a project has her own representation of the system, and he talked about the human system “above the line” rather than about the system “below the line”.
“When you understand that to create resilience you work above the line [with people], a lot of things change”, he said.
Allspaws words resonated with me as I don’t see testing as an activity about a product. Rather, I see testing being about people, specifically what is on their minds. I wrote about that in my last blog on testing and Immanuel Kant.

Why are we still Suffering from Sluggish Delivery?

I found a book with new English translations of essays and letters by the stoic philosopher Lucius Seneca in a bookshop in London. Interestingly, Seneca’s words offered me a new perspective and thishas lead me to a possible answer. Here’s a quote from Seneca:

As fire tests gold, so misfortune tests brave men.
– Lucius Seneca in “On Providence”, an essay written around 50 AD

Let me explain what this means to me:
At Seneca’s time, the quality of gold was proven in a testa. A testa is a pot of clay which was heated over fire, melting the gold. The noun for the clay pot is now the verb test.
Testing software is more complicated than testing gold, but the value of testing in the Antique persists: Testers are often tasked to prove quality.
Seneca wrote “On Providence” to answer a question from a friend: “Why, if the world is governed by providence, it is still the case that good men suffer from many misfortunes”?
With a slight hint of sarcasm, I’ll reframe the question to the modern context of struggling IT-projects, and ask why, if we’re doing Everything Agile, is it still the case that we suffer from sluggish delivery and bugs in production?

The Importance of Testing

Seneca’s answer is that we shouldn’t think too much about success, fortune, and happiness. He says that we should remember that misfortunes are not random events to avoid and forget: “Only a great man is able to triumph over the disasters and terrors afflicting mortal life.” Greatness, to the stoics, was not what it is to most today: Success. Rather, Stoic greatness is about our psychological fortresses against bad fortune.
In CD, we build frameworks of unit tests to reject code check-in’s and put regression tests in automated pipelines. Automation can prove quality if it is kept maintained and focused on what matters to the business.
But as Allspaw points out, CD is not about automation, but about the system “above the line”. Thus, there seems to be a fortune of testing right in front of us:
I think great software testing has a very important role to play in Continous Delivery, but the role is not only about automating regression testing and fortifying and proving the value of a product.
Rather we should think of testing as a way to create a reality in which failure is not only acceptable, but a safe and desirable way for the system “above the line” – the people in the project – to prove its value.
The driving principle of testing in CD could thus be:

Test continously to continously learn

References:

• Elisabeth Hendrickson: Care and Feeding of Feedback Cycles. Opening keynote at Pipeline Conference, London March 20th 2018
• John Allspaw: Poised to adapt. Closing keynote at Pipeline Conference, London March 20th 2018
• Seneca, Dialogues and Essays, A new translation by John Davie. Oxford World’s Classics, 2007
• Stoicism, Stanford Encyclopedia of Philosophy