Eight sessions is a lot. Especially when they are as interesting and informative as the eight I picked out from the 4 available tracks at yesterday's PIPELINE 2018 conference. Today, my head is pounding in a way that I don't recall since I was a teenager cramming for exams.
It does not help that I am not really a pipeline person, although that depends on your definition. Under Daniel Jones' post-DevOps model I sit in AppDev. I did recently do a year as a contractor in PlatDev but that didn't dispel the extra effort required to understand as an outsider looking in. Perhaps live-tweeting all day was too much for my brain, but as a sponsor I was keen to be taking part in the conversation.
That said, I was struck by the extent to which the concerns of a senior developer in AppDev overlap with the concerns of everyone else. For example, Elisabeth Hendrickson - an expert in post-Agile Quality Assurance - spoke brilliantly on the importance of feedback cycles. Unless you are an unusually blinkered cart-horse developer, content to be ordered around, then it is likely those feedback cycles are something you attend to daily. More likely you are a wide-eyed cat: impossible to herd but highly attentive to what matters - and feedback matters. So Elisabeth's talk was for you, even if you have barely started along the path to Continuous Delivery (and if you haven't, it was full of good reasons to do so).
Likewise, the testing open space focused on testing in production, something the attendees remained uncomfortable with (perhaps rightly so given the pessimism of developers towards development) and with getting a QA team to open up, cease being a gatekeeper and integrate with everyone else.
Jafar Soltani perhaps had the least to offer AppDev. It was pitched at intermediate on the schedule but too much time was spent talking about the basics of Continous Delivery. Juxtaposing that material with "and this was hard for video games" didn't seem to result in as many new insights as I had hoped. The content around the particulars of his build pipeline were more interesting, even to me, as he had a couple of unique challenges: very long build times for his C++ codebase and a high proportion of binaries. I was, however, entertained by the idea that if his ecommerce component went down, his in-game shopkeeper would put a closed sign on the door and wander off. Better than crashing the game, of course, but not something real online shops would put up with.
I skipped out of the Q&A and went over to see the end of Daniel Jones' talk on Continuous Delivery being better for the Brain. This idea that systems can and should be tailored to neuro-biology is something I strongly agree with. My own Nagios Chart pet-project at the FT, of which I am still immensely proud, uses insights from a similar space (albeit pre-digested into a Neal Stephenson novel). I ruminated over the idea that a projection of system state over time is, in effect, a feedback loop per Elisabeth Hendrickson and a visualisation with high Anthropic Sympathy per Daniel Jones. Although this interests me a great deal, and is relevant to everyone (I can even think of a few reasons for politicians to take note) I found nothing new in the last 10 minutes that I did not get from the version on YouTube. However, it is often the Q&A that takes off and there, and on twitter the discussion was focuses on something else: Daniel doesn't like deadlines and puts forward good arguments that they are superfluous below the line of the Product function. Twitter did not agree.
Fatigue began to really set in for "Leadership in Agile/DevOps environments" with Michiel Rook but as the man said. If you have a mission then sometimes that must be primary, even if it makes you hungry cold or sleepy. As someone anticipating a move to lead, either by scaling Agile Stationery or going back into contracting, I was looking for something to help calm nerves about that. Rook provided a checklist of personal attributes that are not straightforward to change, but also a menu of leadership styles and guidance about when to choose each.
One coffee later, Chris Young used physical cardboard boxes to represent ARPANET nodes as he gave a peripatetic description of ARPANET's founding. As an advocate of paper tools in teams I got why he did that - although it did not stop me asking him to be explicit about it. It showed how damned hard some of the basic infrastructure was to set up in that era. Even doing it with paper and string probably took longer than some whole applications take to set up in AWS today. What was also interesting was how remote management and regular releases, as well as measurement interfaces being built into routers allowed the ARPANET to evolve quickly into the Internet we know today.
I regret that John Allspaw's talk was compressed into Dave Farley's slot due to snow forecast for New York. John's talk was intended to join together the community of intellectuals focused on Continuous Delivery with the community of intellectuals focused on critical systems safety (aeroplanes, surgical procedure, nuclear plants were some of the example domains). Apparently the Resilience Engineering community (to give it it's name) were very impressed with the thinking around CD as a source of necessary adaptive capacity to ensure systems kept working. Allspaw also argued that we should appreciate the best of the insights from Resilience Engineering. The consequences if we don't may extend to poverty and death, in the short term, or choking regulation in the long term. If there is one thing I don't like the sound of then it is choking regulation - a source of more poverty and death than any single outage ever could be. I regret that anyone has the power to threaten that, but accept that threat is real. After all, people have been talking about licencing programmers for more than a decade. Scary stuff.
Dave Farley managed to use all of John Allspaw's time and then-some to offer up a menu of options for making pipelines go faster. Much of the menu will be familiar to pipeline people and computer scientists more generally, but his insights into where to prioritise and what timescales were to be accepted were interesting, as were his stories about what happens to team dynamics when pipelines are sped up and feedback is available multiple times a day.
So, plenty to chew over. And a tiring and busy day. I'm delighted to hear that PIPELINE are considering a second day in the program for 2019. I think they are going to need a bigger boat.
