About a month back, I visited Seattle to attend the first ever DeliveryConf. This event is focused on sharing practical, hands-on experience with delivering software to an audience of technical folks. Each talk was driven by stories about success, failures, design choices, tooling preferences, goals, and outcomes. Given the list of presenters and a the Tweet thread below from Emily Freeman, I signed up.
Additionally, there was a group discussion that followed every presentation with everyone invited to join the circle and share their thoughts on the topic (with a staff member holding the mic to prevent anyone going rogue). This would normally be the “hallway track” at any other event, which is great and all, but having it structured, on topic, and recorded for later sharing was a superb idea. There was plenty of hallway discussions going on as well.
In this post, I’m finally organizing my notes and putting together some thoughts on a few of the presentations. There is no particular order or ranking for what I’m sharing here in this post. I attended a total of 8 sessions, 3 keynotes, and 1 keynote panel. All of the presenters were experienced, topical, and passionate about the continuous delivery ecosystem; I didn’t witness a single bad talk.
Note: You can watch all of the videos from the conferences for free by visiting this YouTube playlist.
Divining the Future with Dave Farley and Jez Humble
There was a sense of excitement and learning throughout the conference, especially since both Dave and Jez were floating around, giving talks, and participating in the group discussions. In their opening keynote, entitled “What Will The Next 10 Years Of Continuous Delivery Look Like?“, both presenters took a trip through a decade of experiences as authors of the Continuous Delivery book (highly recommended).
A few nuggets that I managed to pluck out of their DeliveryConf presentation and record in my journal:
- Function is more important than beauty, however, it is critical to optimize for feedback.
- If the authors could have done it all over again, they would have talked more about engineering, culture, and security.
- Executives are the problem.
- The optimization of learning and managing complexity should be top priorities for any would-be elite performers.
- The Scientific Method remains an important and often under-valued tool in software development. (26:52 in video)
- The CEO leverages predictability to meet employee, customer, board, and stakeholder expectations. The adoption of continuous delivery vastly improves the ability to model and predict delivery.
I also picked up on the term “Watermelon Status Report” during the presentation. I later recalled seeing this in The Unicorn Project as well.
Putting Continuous Delivery on its Head with Bryan Liles
Another fantastic keynote presentation entitled “Re-imagining Continuous {Integration | Delivery | Deployment | Whatever}” was delivered by Bryan Liles. I appreciate his inclusion of a choose-your-own-adventure style array of objects to insert into the title. If you’re into LEGO, 80’s computer games, and have opinions on tooling, this is a good presentation to view.
This DeliveryConf talk was much more about gathering decades of experiences and condensing them into a cohesive theory that Bryan wanted to share with the group. He hopes that folks challenge his ideas to make them even better, which I applaud. A few good points that I managed to scribble down:
- “We like to take good things and combine them into worse things.”
- Treat pull requests (PRs) as full blown environments.
- Build only what is needed or desired.
- LEGO bricks really hurt when trampled upon by human feet.
- Simplification is key; there is so much complexity added to many CI/CD systems that can be wiped away.
It was a bit hard to write because I kept laughing so much at the stories that Brian shared. ?
Crafting Homeycomb’s Observability Offering with Liz Fong-Jones and Danyel Fisher
The final presentation of DeliveryConf was given by Honeycomb. Liz and Danyel talked about “Fast & Simple: Observing Code & Infra Deployments At Honeycomb“. This journey was all about their organization’s decisions around technology and delivery as told by two of their engineers. Honeycomb runs a small, lean team – this means that some decisions are going to be driven by that, such as the reduction of complexity when constructing their technical designs.
I wish that my brain wasn’t a pile of mush after two days of continuous delivery of information! It’s not that often that I hear a company revealing how an outage was formed, what steps were taken to discover the root cause(s) in a blameless retrospective, and how they deliver code.
- The first section (3:00) is all about how Honeycomb invested to reach where they are today. The road map, choosing tooling, being thoughtful, and deciding what to build, re-use, or consume.
- The next section (5:32) focuses more on shipping features into production. The “recipe” shared here is very groovy: instrumentation, testing (including TDD), functional / visual testing, feature flags, automation, and more. The production, dogfood, and kibble environments were also described quite well.
- We find the next section (18:05) discusses infrastructure. I found this to be the most ear-perking section. Liz talks about the goals being
reliability and simplicity and shares thoughts on what happened when joining Honeycomb and how the architecture has been arranged and automated. - The journey continues (26:03) with some story telling around building a trusted, blameless ecosystem to tangle with failures. The perfect storm that resulted in a small outage stemmed from four separate downstream causes that coalesced into customer pain: code that wasn’t building, experimental CI, deploying empty binaries, and lack of health check / rollback. All things we’ve dealt with in some way but rarely find pieced together and shared on a stage.
- The final bit (34:24) is about moving forward. This contains some future facing ideas and projects along with a link to the A Culture of Observability Helps Engineers Hit the Spot (Instance) blog post.
I shared some of my early thoughts in the tweet below. ?
Other Recommended DeliveryConf Sessions
Here are more sessions that I attended in person and took down some notes. I tried to tailor this to areas that interest me personally and professionally.
- A Whole Team Approach To Testing In Continuous Delivery – Lisa Crispin did a fantastic job and was one of the presenters I was excited to meet in person. I’m not a tester by trade and wanted to learn more about adjacent ecosystems.
- Continuous Delivery For Machine Learning: Patterns And Pains – Emily Gorcenski rocked this session! “Don’t seek problems you don’t have because solutions exist” was a mic drop moment. ?
- Progressive Delivery Patterns In The Wild – Dave Karow went straight to ludicrous speed with this session. Lots of great references to studies and surveys along with customer stories and public use cases. Dave also published related resources here.
- Tools For Builders: Crafting User Experiences For Technical Practitioners – John Ryan is obviously passionate about user experience. His description of flow was spot on. The idea of shaping a tool to maximize the capability of a human, while also remembering the problem and the person’s role, was powerful stuff.
DeliveryConf 2020 Thoughts
The amount of effort that Sasha Rosenbaum and team put into DeliveryConf was spectacular. It was obvious that they took a collection of the “good things” that we like about in-person technical events and distilled them into a quality conference. The group discussions that followed each session and keynote were highly valued; I enjoyed the back-and-forth on different sticky issues related to continuous delivery.
If the organizers decide to do another one of these, I’m definitely going to try and make it back out. ?
Next Steps
Please accept a crisp high five for reaching this point in the post!
If you’d like to learn more about Continuous Integration, or other modern technology approaches, head over to the Guided Learning page.
