For a while there a few days ago it sure seemed to some as though the Google Chrome development team had proven again that no matter how much bandwidth is made available, someone, somewhere, for some reason, is going to need or want more.
Instead, what really occurred was a lesson in the everyday risks that can come with free-wheeling corporate blogging.
Here's what was posted to the Google Chrome Releases blog on Friday by program manager Mark Larsen:
"We were not able to issue a Dev channel release this week. Our test team did a great job in qualifying two Stable updates and a Beta update this week, and we just didn't have the bandwidth to push a Dev channel release. We'll get an update out early next week. Stay tuned for some exciting new features we hope to land in the Dev channel."
Which prompted a ZDNet blogger to write:
"It sounds like there isn't going to be a dev channel release of Chrome this week - simply because they've already updated the stable, and beta channels this week, and simply can't do any more because they ran out of bandwidth. ... You wouldn't think bandwidth at Google would be an issue, but it sounds like it can be."
An industry analyst sent me the ZDNet link yesterday, noting: "I thought this was pretty funny -- Google running out of bandwidth."
By which time the Google-sucked-up-all-its-bandwidth report already had been picked up by this blogger and this one and this one ... and this one that appears to be informing a presumably thunderstruck Chinese audience ... and, I believe, this one, although I don't speak the language.
One can only imagine the fallout were such a Google bandwidth crisis actually true: Service providers would be rushing out press releases touting the depletion as proof positive of the need for bandwidth caps. A congressman might smell a headline opportunity. Heck, Wall Street might wonder if the recession has hamstrung Google's R&D. ... Bailout?
But, alas, the facts once again get in the way of a great story:
Google's Larsen updated the blog post yesterday:
[Edit, 11 May 2009: Change 'bandwidth' to 'test capacity'. Sometimes the colloquial jargon we use at work translates imprecisely for a public audience.]
Ah, test capacity; colloquial "bandwidth," not real bandwidth. Well, it's still kind of interesting to learn that even at Google -- $129-billion-dollar market cap Google -- resources remain finite.
Welcome regulars and passersby. Here are a few more recent Buzzblog items. And, if you'd like to receive Buzzblog via e-mail newsletter, here's where to sign up.
4chan users trigger DDoS attack ... against 4chan?
What does security software have to do with swine flu?
Domain name company cries croc tears over "censorship."
Snopes.com gets an "A" from fellow fact-checkers.
Reason No. 2 to resist filing a complaint with the FCC.
2009's 25 Geekiest 25th Anniversaries.
Melissa virus turning 10 ... (age of the stripper remains unknown).
Tweeting with "Star Trek" actor sparks kitchen fire?
40% of geeks surveyed admit to working ... how many hours?
The Leader in Network Knowledge
Developer Jargon
This is interesting as I immediately got the point of the post - bandwidth in relation to resources vs. network bandwidth. It is a good reminder that the day to day techno and PM speak we use can be misconstrued by the masses.
EXACTLY. Bandwidth doesn't
EXACTLY. Bandwidth doesn't always mean network throughput, how hard is that to understand?
It's worth noting that the
It's worth noting that the source for chrome is 600MB, but the build result is a magnitude smaller. Their build process is time consuming and includes a lot of unit tests.
wow
what an awful story. I can't believe you guys would even print this crap??
this is not so surprising
Even a large company has to distribute resources carefully. Applying too many resources to a single problem can cause MORE problems than applying too few. The overhead of coordinating extra people can weigh a project down (Mythical Man Month). Lack of resource pressure can lead to complacency, which in turn leads to poor utilization and lack of direction (if you aren't forced to prioritize what matters, you will lose focus doing all the extra things those extra resources afford you).
So it's not surprising that for all its global staff, Google assigned a specific amount to this project and from time to time, the project will see local spikes in workload that exceed capacity. As long as this is not a chronic condition (suggesting a poor staffing choice), this is fine.
Then the question becomes, when team capacity is exceeded, if this is a temporary condition, does the situation merit reassigning people from another project?
This situation clearly does not merit injuring other projects. If you presume those other projects are also thoughtfully resourced, you'd be disrupting them considerably by robbing them (even temporarily) of people.
Since there's ramp-up / training time in a temporary transition like this, the net loss of a week from another project would NOT result in a net gain of a week on this one. Thus fine-grained load-balancing would LOWER the overall efficiency across multiple teams and should be avoided except in emergencies.
This means the best decision is for the team to "suck it up" and accept that they got done this week and they'll have to set their sights on
next week.
ack - looks like I angle brackets are stripped
I guess my angle brackets were taken as HTML. That last paragraph should have read:
This means the best decision is for the team to "suck it up" and accept that they got [amount of work X] done this week and they'll have to set their sights on [piece of work Y] next week.
Wow
You do know that Google is going to rule the world one day right?
RT
www.privacy-resources.us.tc
They don't already?
They don't already?
Not Internet Bandwidth you Noobs
Learn the language, they didn't have the human resources to do this is what he meant. Maybe because the test team is working on something else. They are not talking about actual bandwidth, what a waste of time.
Duh
Awful story. "Our test team did a great job in qualifying two stable updates..." They're obviously talking about human time, why even write about this?
Post new comment