Slow stable releases or fast unstable releases?

The real choice: Big pile of poo, or small, managable piles of poo?

“I don’t care if we spend three months between releases, if we can get it stable.”

I was recently told this by a CEO frustrated by the bugs in production, after a recent switch from GitFlow, with weeks-long manual QA, to trunk-based development.

When he said that to me, this popular meme popped to mind:

Software creation is a messy process. It’s a process of discovery, and discovery is never safe or easy. If there’s one thing we’ve learned over the years, it’s that the choice between “slow and stable” or “fast and unstable” is a false choice.

My reply to him was: “The real choice is between waiting three months for a huge pile of sh*t, or getting small, manageable pieces of sh*t more frequently.”

He laughed a bit. But then I asked him to consider the team’s track record before the switch to trunk-based development. It was delivering buggy software then, too. The slower pace hadn’t solved that problem.

And this brings to light a key problem with meme above. Two problems, really. The more important problem is that it ignores the clean-up that happens after delivering a pile of poo. It also forgets (perhaps intentionally, perhaps naively) that there are two “agiles” out there: The one it’s making fun of, which is really just waterfall in disguise. It’s delivering increments, but without adapting. And then there’s “real agile”, which is all about adapting to new information (including information about bugs).

Here’s my fixed version of the meme:

If smaller pieces of sh*t appeals to you, my free email course on Lean CD might be of interest!

Share this