Breakpoint 2020 is a 4-day virtual summit on everything testing. We're bringing speakers from the best dev and QA teams to talk about building QA processes, automating at scale and best practices for success with tools and frameworks.
Brian Lucas is a Senior Staff Engineer at Optimizely, responsible for build, test and release engineering processes.
Brian enjoys building, iterating, and scaling teams and is an early proponent of cloud computing. He holds four patents and is an active contributor to open source.
What does your role at Optimizely involve?
I focus on leading large company-wide projects in two major areas: Billing and Developer Productivity.
On Developer Productivity, I focus on initiatives that improve our engineering, such as:
- Increasing velocity through more frequent deploys and smaller changesets
- Driving engineering experimentation with feature flags/gating
- Building infrastructure (tooling) to decrease operational burden
- “Shifting left” on QA, experimentation, security, etc. to increase overall developer velocity
On the Billing front, I’m leading efforts to accurately count upwards of close to a trillion events per month, and other areas around feature management, like entitlement.
In general terms, these are tough problems that are difficult to solve and require 9-12 months at a time across multiple teams and departments.
Can you give us a sneak-peek into your session for Breakpoint 2020?
My session is titled, "How to win in software development with tighter feedback loops".
Engineering organizations crumble under their own weight without proper investments in fast, reliable, modular mechanisms to build and test software.
My talk will focus on the specific investments you can make to improve velocity on your build and test processes by focusing on feedback loops. This is applicable to organizations of every size and maturity.
Can you tell us about the patents you hold?
What are you reading/learning right now?
I recently read “Accelerate State of DevOps” from DORA. It shared empirical and anecdotal studies around high-performing engineering organizations seen as innovators in their space. Inevitably, those organizations studied often had wildly different products and approaches to building, but there were many common threads that could be distilled down into meaningful lessons for groups of any size.
Another one is a concept we’ve started to explore, popularized by Netflix, called Hexagonal Architecture, which stems from concepts introduced in 2005. We’ve started looking at this as a way to keep our microservices loosely coupled and avoid challenges when (and if) we have to refactor them in the future.
What would you tell someone new to testing?
Every engineer should know how to test across multiple domains (unit/integration/end-to-end). Leaving the tests to a specific group (eg., a QA team) means that you’ll lose vital context from the author (yourself) and the tests won’t cover all the scenarios you should be covering, including the tricky-to-implement edge cases. Remember, you’re only one emergency away from discovering this truth on your own!