# Run the Dishwasher Half Full

In a perfect world, you would only run the dishwasher when it was completely full.

This makes sense from a resource-management perspective. Full dishwashers mean fewer runs, which means less water, electricity, and soap. You also save a bit of time: you start the dishwasher once, and you can put away the maximum number of dishes at once, achieving a kind of domestic “flow.”

But the dishwasher does not exist in isolation. It’s part of a workflow, and its work comes after the dishes are dirtied. That can happen at various rates.

Try as you might to optimize the number of dishwasher runs, you may eventually end up with a dishwasher so full that you can’t fit all your dishes into it.

In my experience, what happens next is not ideal. The leftover dishes usually sit overnight, and they get weird.

The opposite isn’t ideal either. If you have a half-full dishwasher and leave it overnight, the dishwasher can get weird.

Either way, the next day you might not have enough clean dishes for a meal, because half of them are dirty—in the dishwasher or next to the sink.

So here’s my solution:

Run the dishwasher when it’s half full.

Sure, this will probably result in more runs. It will cost a little more water, electricity, and soap. But you avoid the worst-case scenario: not having enough clean dishes when you need them.

After all, that’s the point of washing dishes.

It’s worth spending a few extra dollars and a little extra time to make sure the dishwasher serves you, rather than the other way around.

So what does this have to do with programming?

Let’s say you do weekly releases. You sometimes ship a little earlier and sometimes a little later. That’s fine.

What’s not fine is keeping a release open for more work.

Releases include bug fixes, features, and customer-requested changes. Every day you wait to ship them is another day those changes are unavailable to your customers.

The answer is unintuitive: cut a release anyway.

Almost every time in my career that I’ve kept a release open to fit one more thing, it has been a mistake. That one more thing almost always takes longer than expected.

Then suddenly it’s the following week, and you would have been better off releasing when you originally planned. If the additional changes were urgent, you can cut an extra, in-between release. If not, you can wait for the next planned release.

A release is not a container that needs to be filled.

It is a necessary process to deliver value. And if it’s on a cadence, that cadence should work for you, not against you.

Ship what’s ready. Feature flag what’s not. And keep rolling.