[FordPrefectAO]

Whatever you are developing has no value until someone actually uses it. Therefore the quicker you can confidently release something(feature, bugfix, etc), the more value you gave deliver.

This idea comes from the concept of inventory waste from lean manufacturing

[suresk]

Another side benefit is that it generally leads to higher quality releases and more stability, for a few reasons:

1) If you can do quick, easy releases, people release small, narrowly-scoped changes instead of huge batches of changes that may interact with each other in all sorts of unknown ways.

2) If you need to fix something, having a process that lets you release quickly and easily means you can get a fix deployed that much sooner. I hate being in a situation where an emergency patch that is really small still takes hours to get out.

[jonny_eh]

Also, if something goes wrong in production, it's easier to find the cause. Just look at the most recently deployed code change.

[mkopinsky]

From that standpoint, frequent releases can also make things harder, depending on the tightness your feedback loop. If it takes you two days for user reports to percolate to you, it doesn't help if there've been 16 releases since then to examine. For the work I do, error reports are usually "A patient called us to report that their daily email had some wrong info", so for that, multiple-times-per-day releases would not make things any easier to debug.

[smu]

Presuming your "productivity" stays the same, you would either have 16 releases of size "1" after two days, or 1 release of size "16". Either way, the size of the code to examine would be the same, right? You would still have the benefit of getting the new features faster to the user, so I would say quick releases are still beneficial.

In your situation, I would look for ways to detect the issues earlier. Ideally, you know about it before the user does (which is easier said than done, I know). Added benefit of this: quicker feedback will help you pinpoint the problematic release ;-)

[sdrothrock]

In addition, faster releases can also reduce sunk costs. For example, if you release new features in stages, you can correct course quickly from the beginning based on actual user use/feedback instead of spending months building up something that may not meet actual needs.

[Can_Not]

This is hugely important. My current employer wants our grand release to have a powerful search feature. We have zero customers to use it and Zero data to search through.

[Outdoorsman]

Agreed...the primary advantage is being able to backtrack quickly...diagnostics are focused...