What's better: short trains that leave frequently or longer trains that leave less often?
Given Google programmers' philosophy of releasing products early then iterating often, it's no surprise that higher frequency is their preference: thus the announcement Thursday that Google will speed up the release cycle of its Chrome browser.
New stable versions of Chrome today arrive about every three months, but Google wants to double that pace, said Chrome Program Manager Anthony LaForge.
"Under the old model, when we faced a deadline with an incomplete feature, we had three options, all undesirable: (1) Engineers had to rush or work overtime to complete the feature by the deadline, (2) We delayed the release to complete that feature (which affected other unrelated features), or (3) The feature was disabled and had to wait approximately 3 months for the next release. With the new schedule, if a given feature is not complete, it will simply ride on the the next release train when it's ready," he said in the blog.
That could mean, for example that some features such as print preview that Google punted from Chrome 6 to Chrome 7 could arrive in mainstream Chrome users' hands earlier.
Browser rival Mozilla is working on the same idea of more frequent releases. As with Chrome, though, it doesn't mean the pace of advancement doubles, only that new features arrive in smaller doses but more often.
For decades, distribution was a difficult matter for the software industry. AT&T and UC Berkeley Unix programmers mailed tapes to one another. And when personal computers caught on, floppy disks and later CDs also relied on the postal service. Software that dates from this era--Microsoft Office, Adobe Photoshop, Civilization--tends toward major updates released years apart.
Google, of course, grew up in the Internet era, when the network could be used to send software. Google likes its software to be updated silently, behind the scenes, and with no user intervention--in short, the way Google updates its search engine algorithm.
Of course, there's still a lot of overhead in releasing software, even as an online update. New versions must be debugged, tested, packaged up, and sent over the wire. It's often easier to handle one bigger train than two small ones. But Google believes its new release process, to be implemented in coming months, will also make project management easier in many ways.
It remains to be seen how amenable Google's philosophy will be to IT organizations accustomed to testing software and controlling its release. Certainly many employees rely constantly on Google's ever-changing search engine, which corporate IT doesn't get to test. But software that runs on a company's computers brings security risks and compatibility challenges not present when visiting a Web site.
Realistically, a release cycle of six weeks rather than three months won't make too much difference to corporate IT geared for cycles many times that duration, so Google's move to turn the crank faster probably won't change things much.
A broader issue also is involved: how fast can people keep up? User interface changes can leave people clicking around in menus and dialog boxes for commands they once knew how to find.
In other words, Chrome is a window on the Web, and it will often be up to Web site owners to worry about making sure people don't suffer future shock.