tag:blogger.com,1999:blog-6569681.post993339521907435012..comments2024-03-24T10:38:16.997-07:00Comments on Geeking with Greg: The experiment infrastructure at GoogleGreg Lindenhttp://www.blogger.com/profile/09216403000599463072noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-6569681.post-26672517195156278902011-01-07T07:44:57.900-08:002011-01-07T07:44:57.900-08:00Hi, Barry. Thanks, that's a good point about ...Hi, Barry. Thanks, that's a good point about pushing binaries in a distributed environment. It might also have something to do with the size of the binary. Amazon had a problem several years ago with a very large binary that took a long time to push (which it solved mostly by splitting into many smaller binaries).<br /><br />But, even if there are reasons that frequent pushes of binaries can be difficult, the point still stands that infrequent pushes impose a lot of hidden costs on developers and the company: It slows the pace of iteration. It forces developers to write more code in case it might be needed. It transfers complexity from code to configuration files where it can be harder to test and debug. It complicates scheduling and slows launches. And, it creates more errors overall by launching large numbers of changes in each push (aka "big bang launch"), which adds much complexity and is harder to test.<br /><br />Because of those hidden costs, I think it is better to push binaries more often than weekly.Greg Lindenhttps://www.blogger.com/profile/09216403000599463072noreply@blogger.com