Hacker News Reader

Comment by Uchikoma | Hacker News Reader

My Chrome is getting buggier all the time (now in version 15). Tabs hang, websites crash.

So to be selfish: Instead of adding a terminal emulator, I want my Chrome from 2 years ago back, which was fast, bug free and did not hang.

View on HN

This just in: there are a massive amount of developers working on a single project. Not all of them are on the stability team. Just because they're adding feature X doesn't mean that they're taking any amount of resources away from bugfix Y. It's a false dichotomy typically imagined by those who have never worked on medium to large-sized products.

It would be false if he had said no work on stability was happening. However, new features come with a cost in stability (both through introduced errors and less manpower on the stability teams). Google has been putting a lot of features in (nacl, dart, etc) and it is coming at the expense of the basic browsing experience.

Interesting that as Mozilla figures out it needs to focus on the basics after getting slammed by the smaller, faster Chrome, Google does the exact same thing they did.

It's just Zawinski's law in a cycle. “Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”

"Various studies have shown that software broadly contains something like 6-16 bugs per 1000 lines of code."

As more features are added, the number of bugs will increase, so in a sense everyone who is not on the stability team is on the instability team. Which means the stability team would need more developers as a counterweight...

Here are a couple of details about programming at Google. First, every commit requires a code review. Secondly, in addition to writing your own tests and testing tools, there is a separate set of developers that do nothing but write testing infrastructure, ensuring that it's as easy as possible to test everything as it's written.

Bugs still happen, of course, but they're going to be of the more obscure variety. My chromium 14.0.835.202 has never crashed. Always good to get a backtrace and read the code nearby, and if nothing makes sense, run memtest86.

That also assumes that throwing more developers on the stability team would fix the problem.

Not necessarily. It only takes one bureaucrat to reject code that doesn't pass tests or follow required conventions. For example, a good rule of thumb is that no new code will be accepted without documentation.

It may help by simply getting the bug-generating developers to do something else for a while.

"It's a false dichotomy typically imagined by those who have never worked on medium to large-sized products"

In my experience it's not necessarily false, especially when the test cycle has a weak regression suite.

One project I worked on was an embedded system with tight resource management requirements. The teams were split into features and stability/performance scrums. Each new feature would have the performance people crying out loud at the new overheads introduced.

A performance/stability-minded code reviewer on each team alongside a strong performance regression test cycle might have seen the project succeed but the pace imposed by a fast agile dev cycle precluded this sort of discipline.

Marketing wanted features and wanted them now - The demo is Friday, chop chop!

Not a false dichotomy but a manufactured one, perhaps.

Yeah, Chrome represents a pretty different model from most desktop apps we run. Chrome's seamless auto-update has brought web-app style continuous iteration to the desktop. That means continuous change, and presumably improvement, but also no real ability to opt-out of new features/bloat and newly introduced bugs.

This was a brilliant move for Google because it removes the friction they face to push web-client functionality where they want it to go. For example, I woke up one day and suddenly I could run all these new webgl apps. We have all granted them implicit license to push code out to all our desktops -- at the cost of no longer controlling what version and bug/feature tradeoff you are running.

Whereas App Store apps, where the user controls updates, are somewhere in the middle of this shrinkwrap vs. web app continuum. You get the constant nagging to download version N.epsilon.epsilon of iTunes, with 20 pages of block text describing updates that are only interesting if you are the person driving Apple's grand product strategy, but you at least get the ability to say no thanks, don't ask me again. (Of course they will ask you again, but that's just due to inevitably skewed incentives.)

I use portable version of Chrome running from TrueCrypt partition for commerce related things (along with Firefox as my main browser) and that way Chrome autoupdates are frozen.

There's probably some kind of law in there. My browser history is Mosaic -> Netscape -> Galeon -> Firefox [1] everytime jumping to a new slender browser since the old one got too bloated or too old. Firefox lost its slenderness a long time ago but I never found anything to replace it with.

[1] I think I missed a few.

Zawinski's law? http://catb.org/jargon/html/Z/Zawinskis-Law.html

How about uzbl (http://uzbl.org/)?

I had the exact same problem. I was very dissapointed of Chrome, until I reformated my computer, when Chrome updated the bookmarks it became slow and buggier... that's when I deleted all of the bookmarks of the Bookmarks Bar, and VOILA!, Chrome was reborn for me.

Same here, I'm back on Chrome 11 on Linux, as the recent ones have been atrocious...

yeah... chromev2 with bugfixes and newest webkit / v8 engine :D

I came here to say exactly this.

Chrome should try and remove features, not add things nobody is asking for.

>Chrome should try and remove features, not add things nobody is asking for.

Can you be a little more specific as to what kind of thing should be removed? I've noticed a definite difference in speed, but I wouldn't say the browser is bloated.

Reply on news.ycombinator.com