I saw one interesting analysis of service bugs. I can't find it now, but the basic point was that people should stop focusing on MTBF (median time between failures) and instead look at MTTR (median time to recovery).
The notion was that it was much better to be able to notice and fix bugs quickly than it was to add process delays that reduced bug frequency. That especially makes sense to me when you think about the value integral. The longer your release cycle, the longer you keep people away from improvements. It also makes sense if you think about companies as learning organizations; speed of learning is limited by the length of your feedback loops.
So I'd say that Google's mistake isn't going for a release-early, release often approach. It's that they don't pay sufficient attention after release to user feedback or user metrics. Hell, I've stopped reporting bugs to Google, and I must know 10 people who work there. Even with a good backchannel I just have no faith that anything would come of a report.
The notion was that it was much better to be able to notice and fix bugs quickly than it was to add process delays that reduced bug frequency. That especially makes sense to me when you think about the value integral. The longer your release cycle, the longer you keep people away from improvements. It also makes sense if you think about companies as learning organizations; speed of learning is limited by the length of your feedback loops.
So I'd say that Google's mistake isn't going for a release-early, release often approach. It's that they don't pay sufficient attention after release to user feedback or user metrics. Hell, I've stopped reporting bugs to Google, and I must know 10 people who work there. Even with a good backchannel I just have no faith that anything would come of a report.