I relate the story of a single bit gone wrong back in 2006, which launched my career on a new trajectory of root-cause analysis, continuous improvement, and DevOps.

In this article, my goal is to clear up some confusion about “DevOps”, and provide some pointers for those who want to learn more.

Frequently we're faced with a decision where blindly following the principle of decide as late as possible might make our lives more painful. Sometimes we can make a choice that's easy to unmake.

This Lean software development principle of "decide as late as possible" is often criticized as too limiting. And rightly so, to a degree.

Every day we're faced with the option, but not the obligation, to do something. This is one of the concepts behind the concept of "deferring commitment" in Lean software development.

If your application relies on serverless functions, often there's limited opportunity for "from an airplane" work.

By working in smaller iterations, we don't just re-organize our work, we actually reduce the amount of work we do.

If every engineer on your team cannot do _meaningful_ work from an airplane, your development environment is broken.

There's almost always more than one way to do something. What workflow does your team use for CI/CD?

In the debate between planned architecture and short iterations, whose right? Both are right, of course.

Is QA a separate stage in your software development pipeline? This is a "smell", an indicator of deeper problems.