Strawberries Are Best When Small

Yes, short feedback cycles are good. But is the trick of the trade ‘small’, rather than ‘short’? The answer will not surprise you.

In this series, we’re trying to find the small, tasty ideas, the “strawberries” that will help us think of agile software development in a way that is difficult to spread too thin, following Jerry Weinberg’s Law of Strawberry Jam:

As long as it has lumps, you can never spread it too thin.

So far, I think we’ve found some important lumps, and some valuable viewpoints, but many of the ideas seem to me to be more like clumps of strawberries, and if we can’t identify the true berries, it’s too likely that well-meaning people will water down the idea, and it’s too likely that the whole clump is too large to eat in one bite.

At our Friday Night Coding Zoom Ensemble last night (Tuesday), Chet mentioned that at an XP conference in Sardinia, he and Sue had been wandering around and bought a bag of strawberries to munch as they strolled. The berries were very small, and very sweet, unlike the giant and somewhat bland berries that we get here.

Separately, GeePaw Hill expressed the feeling that his three shadows thread has had more likes and retweets than his usual numbers, but not as many objections, and not much elaboration or alternative notions as he sometimes sees. He was saying that while he thinks the shadows idea has legs, it’s neither as well-formed nor as “good” an idea as his Many More Much Smaller Steps notion.

Entirely independently of those things that happened last night, which I just mention in passing, I’ve decided this morning to think about “small”.

Small

Yesterday, I mentioned that someone long ago had said that agile was about short feedback cycles, and while I allow that they’re important, I avow that working software is central to agile software development. Who knew?

The thing is this: certainly we want to know ASAP whether whatever we’re doing is good or not so good. Short cycles. And, because we’re doing software, we want to know that about our software. We want that all the time, every day from beginning on, and every moment spent where the software is not good, or we don’t know how good it is, is a bad moment.

That’s what Hill’s MMMSS is all about. That’s what Red-Green-Refactor is about. That’s what short Sprints are about. That’s what pulling one story at a time is about. That’s what slicing stories thin is about.

We need to move in small steps, always stepping from known-good to known-good.

When we’re actually programming, we use TDD’s Red-Green-Refactor to help us choose very small steps, so that we move from known-good to not good and back to known-good in a few minutes. We avoid the day-long, week-long, month-long period where we’re beavering away but nothing is quite working yet.

We pick small stories so that many can be done in a week. We pick one story, and slice it down so that it can be done in a day or less. We think of a test that we can make work in a few minutes.

How Small?

Einstein is supposed to have said

Everything should be made as simple as possible, but no simpler.

There is no evidence that he ever said that, but I found an article that suggests it’s an editor’s paraphrase of something he did write:

“It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

Well that’s not as tasty, but it’s a good lead-in to the question of how small we should make things. But to get there, I need to pass through another story.

GeePaw Hill says in his lead-in to Many More Much Smaller Steps:

A professional chet I know, when asked to give blind advice, always says this: 1) That’s too much rice. 2) That’s not enough garlic.

“Take many more much smaller steps” is definitely blind advice. I have no idea how small your steps are, nor how many you take. I do, however, know how small mine are and how many I take and I can tell you this. For me:

1. That’s not enough steps;
2. That step isn’t small enough.

There I’ll be, trying to take tiny steps, which pretty much guarantees there will be a lot of them, and next thing you know, I’ve been at a red bar for ten minutes, then twenty, then an hour, then two. (I almost always stop at two hours. I should stop at twenty minutes. Probably even at ten minutes.)

Where Are We?

I almost always know where I’m going when I start one of my articles, and I almost always wind up somewhere else. The same is true when I program. I have some goal and path in mind. The path always changes, and the goal often does.

In programming, I think that’s a good thing, and I tell myself it must be OK in these articles for similar reasons, or just because it’s my party and I’ll write how I want to.

And yet here we are.

Perhaps Chet and Hill influenced me after all. I’d have sworn that Chet’s story about small strawberries and Hill’s comments about MMMSS being an idea he feels better about had no impact on my decision to write about small steps in my strawberries series¹.

No. I’m sure it’s just a coincidence, one of those things that you see in threes because you notice the third one.

So I am here to tell you that I came to this conclusion all on my own:

Among the Strawberries of Agile Software Development, perhaps central to it, we find the notion of short feedback cycles based around working software. And the Strawberry of the morning is:

1. That feedback cycle is too long;
2. That’s not enough steps.

Or, and I just made this up:

Take Many More Much Smaller Steps.