Followup: modularity, WebExtensions, and going faster

[Thom Chiovoloni]

A few very ill-advised comments:

On Mon, Oct 10, 2016 at 12:50 AM, Benjamin Smedberg <benjamin at smedbergs.us>
wrote:

> We are shipping these *today*, and shipping is a tedious and fairly
> high-risk process because we don't have modular isolation or testing.
>

I don't think that modularity is the problem here. After all, its very
possible to have bugs in systems where every component works as specified.
(I'd even argue that -- depending on how you define "component" -- this is
where most bugs occur.)

On Mon, Oct 10, 2016 at 12:50 AM, Benjamin Smedberg <benjamin at smedbergs.us>
wrote:

> But let's say that atomic sync is something that we believe is important:
> I believe we *have to* spend the time to reorganize the system so that sync
> as a module that stores passwords, bookmarks, etc is lower/more basic in
> our module structure, and then we build our bookmarks UI, location bar,
> etc, on top of that core structure. We are in charge of designing these
> things.
>

While this is true, I feel like it misses the larger point. Perhaps I'm
projecting my own feelings onto Richard's comment, but the way I
interpreted it, atomic sync was just an example of a feature that
necessarily crosses module boundaries. I don't think there's any possible
way we could possibly enumerate and plan for all of these -- trying to do
so would undoubtedly fail.

And so our choice would be almost exactly the same as it is today: Either
we rewrite large parts of Firefox, or we have a low quality implementation
of the feature... Except, if anything, the rewrite is even harder, since
the boundaries between the modules are even more rigid, and some of them
are even on separate shipping schedules... (And while I agree that it's
obvious that if we care about the feature, the rewrite is the correct
choice, I'm not sure I think that means much.)

I'm not going to be one to say modularity is bad *per se*, but I don't
think it's that clear of a win either. As I see it, you're making a
trade-off: you give away flexibility (the ability for anything to poke at
anything), and you get 1. some code simplicity and 2. the ability to update
modules independently in return.

The code simplicity is valuable, certainly (and I'll get to this), but the
ability to separate modules to the point where they're effectively
different products with different shipping schedules is (to steal a point
made by rnewman in IRC -- sorry!) possibly the most Conway's Law thing
imaginable.

As for the code simplicity, I'm somewhat skeptical that it would be a real
benefit. It seems to me like all that would really happen is that the
complexity would be moved to the module boundaries, which is, IMO not where
we want it (as I mentioned above, you can still have bugs in a system where
every component works as advertised, these bugs are just harder to track
down and prevent through testing).

Anyway, it's very possible that I'm being, err, naively negative here (I'm
sure there's a better word for this, I simply can't think of it...). I
usually try to keep my mouth shut for these discussions, since I'm
nigh-undoubtedly the least experienced person commenting here (what with my
grand total of ~7 months of hacking on Firefox, and ~7 years programming),
but I felt like I needed to say something, despite the fact that I might be
missing the bigger picture.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161010/8bea470d/attachment.html>