Good Software is a Series of Little Failures

The small batch approach to development

Thinking in terms of small batches is one of the key mind-shifts required to become a cloud native organization. By “small batches,” I mean identifying the problem to solve, formulating a theory of how to solve it, thinking of a hypothesis that would prove or disprove the theory, doing the smallest amount of code needed to test your hypothesis, deploying the new code to production, observing how your users interact with the software, and then using those observations to improve your software. The cycle, of course, repeats itself.

This whole process should take at most a week — hopefully just a day. All of these small batches, of course, add up over time to large pieces of software, but in contrast to a “large batch” approach, each small batch of code that survives the loop has been rigorously validated with actual users. Schools of thought like Lean Startup reduce this to helpfully simple sayings like “think, make, check.”

In contrast, “large batches” carry larger risk

A large batches approach follows a different path: we document a pile of requirements up front, developers code away at implementing those features, perhaps creating “golden builds” each week or two (but not deploying those builds to production!), and once all the requirements are implemented and QA’ed, we finally deploy to production. With the large batches approach, this pile of unvalidated code creates a huge amount of risk. This is the realm of multi-year projects that either underwhelm or are consistently late. As one manager at a large organization put it: “We did an analysis of hundreds of projects over a multi-year period. The ones that delivered in less than a quarter succeeded about 80 percent of the time while the ones that lasted more than a year failed at about the same rate.”

Improving taxes with small batches

A great example of this approach is the IRS’s story of how it’s improving the process of looking up how much money they owe. In building out software for this previously manual, phone-driven drudgery, the design team at first thought they should create a UI that presented the complete history of payments and transactions with the IRS. When this approach was tested with actual users, it proved to be overwhelming for taxpayers. By following a small batches approach they finally winnowed down to a more streamlined interface that users validated as more useful.

Embrace failure to be successful

Rethinking and embracing “failure” is a key organizational change here. You — and your organization — have to shift from thinking of “failure” as career cataclysm to thinking about it as a synonym for learning. As you use a small batches approach, you’ll find that you “fail” often: the how you chose to code up the associated hypotheses will often “fail,” or your theory may be hopeless. The point is to start the process over again with the benefit of failure-driven learning and get closer to “success” next time, as the chart below illustrates:

You can hopefully start to understand how this “two steps forward, one step back” approach can start to transform your software delivery capabilities into a consistent, reliable, and highly risk-managed process. It also dovetails with one of the unspoken secrets of software: it’s really hard, if not impossible, to get it right the first, second, or even twentieth time. You have to keep thinking, making, and checking until you figure it out. Thankfully, with the right small batches mindset in place and an organization that supports a failure-driven learning approach, you can create software that’s actually useful, one small batch at a time.

✹

This article is part of Built to Adapt, a publication by Pivotal that shares stories and insights on how software is changing the way businesses are built.