Tradeoffs in the Software Workflow
Software becomes valuable when it is released to users. DevOps methodology and works like “The Phoenix Project” rightfully point out that a major goal is to reduce the amount of “work in progress” - features that are in development but not released aren’t providing value, and tend to be less stable. Research from DORA in works like “Accelerate” provide a statistical justification: high performing software organizations ship small changes constantly, and have higher velocity and stability as a result. And yet, when we conceptualize the software workflow it seems like we have a lot of steps and processes: design, development, unit testing, code review, presubmit testing, submission, post-submit CI, integration tests, release qualification tests, canarying, monitoring, release.
In this talk we’ll try to make sense of two forces that seem to be in tension: fast workflows and release processes vs. the ever-expanding galaxy of workflow best practices. Along the way we’ll propose mechanisms to compare the value of defects spotted before release, and tie all of this back to fundamental definitions of software engineering: programming mixed with time and other programmers.
Titus Winters
Titus is a Senior Staff Software Engineer at Google, where he has worked since 2010. He founded Abseil, Google’s open-source C++ library that underpins more than 250M lines of Google code with 12K+ active internal users. He is one of the four arbiters for Google’s official C++ style guidelines. For the last 10 years, Titus has been organizing, maintaining, and evolving the foundational components of Google’s C++ codebase using modern automation and tooling. Titus is the former chair for the Library Evolution Working Group (LEWG) in WG21. He is also the lead author for the book “Software Engineering at Google.” (O’Reilly, 2020).