I think "short release cycles give you wonderful things" is very on-point for startups. Switching to them has been a boon to BCC and to many of my clients who could lose BCC in the petty cash drawer.
Consider a software company which does yearly releases -- not that uncommon. Averaged over time, there is six months of developer labor which is structurally incapable of helping out customers. That's crazily wasteful. The code is written. It works (well, you know). But, for process reasons, it just can't be put into production right now. It's like having six month timelines on receivables for work already completed and accepted: egads, that's a problem.
That also means that, on average, every new feature laid has a six month air gap between when it is completed and when Real Customer Feedback starts coming in about it. The developer has already forgotten what they did and the design rationale for it.
Six months is also plenty of time for development to go totally off the rails, into the well-trod territory of producing working code which does not provide customer or business value. I've sunk months into features which didn't go anywhere. I have clients that have man-years invested into core features of new releases which were never even seen by plural percent of the user base.
By comparison, if you're releasing bi-weekly, you generally have one week between completing a feature and when you start getting feedback. You have one week for things to get off the rails prior to customer behavior measurably saying "This? Yeah, couldn't care less." You might actually remember design rationales for things you did when called to improve upon them.
The utility of this pretty much keeps increasing the lower you get your iteration times.
Fog Creek used to do yearly releases, largely as an artifact of selling software which had to be installed on 3rd party servers. Like almost everybody else, they have largely transitioned to hosted SaaS. This means they move quite a bit faster now. That has been pretty much unalloyed Good News, both for the engineers and for the business as a whole.
You can plan 100 features, implement 100 features, launch 100 features, get feedback on 100 features
OR
You can plan, implement, and launch 1 feature, get feedback on it, then move on to the next feature, and repeat 100 times.
Obviously, the feedback in the 2nd case is much more immediately useful; the point of the post was that even in a relatively simple case where you wouldn't expect nearly as much value from the feedback (stuffing envelopes), the small-batch approach still wins.
Again, I think that's too strained. In stuffing the envelopes, you can learn everything you need to know about the next 99 iterations from the first one.
In implementing features, the lessons will be different almost every time.
Timescale is also completely different. You can do 1 envelope at a time because there's no waiting involved.
It takes time to evaluate the result of implementing a feature. Not because it's so much work, but because you don't control the factor that really matters: The customer.
You have obviously never stuffed 100 envelopes if you think you learn everything you need to learn from the first one. If you attempt to be mildly efficient about it your process has continuous improvement. "If I spin this pile 90 degrees I can start the folding easier." There are things you don't realize until you've done 5 envelopes, done 10 envelopes and done 100 envelopes.
