Hacker News Reader

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

View on HN

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.

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 ;-)

Reply on news.ycombinator.com