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.
Advertisement
