evan_tech

A lesson I've learned from working on Chrome is how core tradeoffs are to engineering. Working on it as a public project has made me especially aware of how non-obvious that is.

This thread serves as a nice example. Few would dispute that showing a preview of a feed would be nice; but to do so means you need a feed parser, itself an enormous task, and in the Chromium world parsing complicated document formats means you need to do the parsing a sandboxed subprocess. It's not unimaginable to implement (one of the boring things about this sort of project is that you can see the end from the start, and the journey is just a bunch of typing), but in doing so you haven't implemented any number of other things.

Another way to phrase that is to say that to warrant implementing extra feature X, it would be reasonable to state feature Y that will not be implemented because of the time spent on X. I think of this when I think of our sad lack of a Linux port, the project I joined the team for. Working on such on thing would not only have meant I couldn't have implemented e.g. the new tab page and the history snippeting system; it would also mean that the rest of the team would have felt the drag that we are feeling now as any checkin can break the build on two other platforms, sometimes requiring you to patch your change over to those platforms to diagnose it on each.

So what would I have cut? You could argue the new tab page is on the frivolous end of things, and maybe we didn't need history search, though we got a lot of flak for our lack of features already as well as the weak bookmarking system which in fact was the result of this sort of cutting (as was feed support, for what it's worth -- I implemented some of it). Or maybe something more fundamental: maybe we could've gotten away without sandboxing since we're such a small target. But never in any discussion of pet feature X is a discussion like that: what should have been cut to make that feature happen? In that light I laugh at many comments like this one, on the release:

Where the FUCK is the autoscrolling feature that every other browser has? Yes, even I.E. has it.

In reality, a huge amount of invisible work was put into stability in particular: so maybe that person would've been appeased with something that could autoscroll* and would crash just a little bit more often. But that's not how they think about it. They are instead personally slighted (internet-enraged! wrote FUCK in CAPS!) about missing features.

More briefly, this is yet another instance of "you can't please everyone". I myself am also not pleased that I haven't yet been able to run Chromium on my computer, but working on this project has been a good lesson in the sorts of hard decisions that are made to get something this huge out the door.

So now when Boodman recently posted about whether extensions should work per-profile or per-install, I can realize the thread will be fruitless in that it was read as "should we implement feature A, B, or both?" And the answer to that: both, always.

* In case you're unfamiliar: on Windows some mouse drivers (I believe that's the layer it was originally implemented at, at least) make it so middle-click sets a reference point and changes the mouse cursor, and moving your mouse away from that reference point scrolls the page. For what it's worth this one was implemented by WebKit and is in the trunk builds of Chromium.