“Ship early and ship often”. It is a mantra. Ship early, measure the effect, adjust, ship again. Rinse and repeat.

The most often mentioned benefit is that by shipping early and often you can adjust course as you go and not venture down the wrong path for too long.

That’s extremely important. You don’t want to spend months on something and then find that it’s useless.

But, another advantage that I think is often overlooked is perhaps as important:

Improvements compound.

Shipping something early might only yield a 1% improvement by itself. That might not mean much in isolation. However, by shipping these small changes as often as possible and as soon as they’re discovered they compound on each other and produce a much larger effect together. A small change doesn’t mean much but it makes each subsequent change more effective.

Another way of demonstrating this is by imagining you could work and wait till you have a million dollars. Then you invest all your money at once. Alternatively, you could invest any spare money as it becomes available. In this scenario, even if it’s a small amount it immediately starts paying dividends. So by the time you have a million the first 10k would have had lots of time to accrue and would have grown to a lot more.

Code is just like that.

By the time that huge feature is done, the little lowly change that preceeded the entire effort might have had months to improve your service even if just by a little bit. But, over a long period of time it’s effects aren’t negligible.

SCRUM advocates for practices that achieve this effect as well. A usable version needs to exist at the end of each sprint. It might improve the service only marginally but if shipped early it immediately starts compounding.

So, ship early and ship often: it pays dividends.

PS. Improvements in other parts of the business compound as well. Shipping early and often as part of process development works well too. It’s often more difficult because data about the processes is not as easily available.