Frameworks vs libraries (or: process shifts at Mozilla)



All timestamps are based on your local time of:

Posted by: stak
Tags: mozilla
Posted on: 2016-01-31 13:26:07

At some point in the past, I learned about the difference between frameworks and libraries, and it struck me as a really important conceptual distinction that extends far beyond just software. It's really a distinction in process, and that applies everywhere.

The fundamental difference between frameworks and libraries is that when dealing with a framework, the framework provides the structure, and you have to fill in specific bits to make it apply to what you are doing. With a library, however, you are provided with a set of functionality, and you invoke the library to help you get the job done.

It may not seem like a very big distinction at first, but it has a huge impact on various properties of the final product. For example, a framework is easier to use if what you are trying to do lines up with the goal the framework is intended to accomplish. The only thing you need to do is provide (or override) specific things that you need to customize, and the framework takes care of the rest. It's like a builder building your house, and you picking which tile pattern you want for the backsplash. With libraries there's a lot more work - you have a Home Depot full of tools and supplies, but you have to figure out how to put them together to build a house yourself.

The flip side, of course, is that with libraries you get a lot more freedom and customizability than you do with frameworks. With the house analogy, a builder won't add an extra floor for your house if it doesn't fit with their pre-defined floorplans for the subdivision. If you're building it yourself, though, you can do whatever you want.

The library approach makes the final workflow a lot more adaptable when faced with new situations. Once you are in a workflow dictated by a framework, it's very hard to change the workflow because you have almost no control over it - you only have as much control as it was designed to let you have. With libraries you can drop a library here, pick up another one there, and evolve your workflow incrementally, because you can use them however you want.

In the context of building code, the *nix toolchain (a pile of command-line tools that do very specific things) is a great example of the library approach - it's very adaptable as you can swap out commands for other commands to do what you need. An IDE, on the other hand, is more of a framework. It's easier to get started because the heavy lifting is taken care of, all you have to do is "insert code here". But if you want to do some special processing of the code that the IDE doesn't allow, you're out of luck.

An interesting thing to note is that usually people start with frameworks and move towards libraries as their needs get more complex and they need to customize their workflow more. It's not often that people go the other way, because once you've already spent the effort to build a customized workflow it's hard to justify throwing the freedom away and locking yourself down. But that's what it feels like we are doing at Mozilla - sometimes on purpose, and sometimes unintentionally, without realizing we are putting on a straitjacket.

The shift from Bugzilla/Splinter to MozReview is one example of this. Going from a customizable, flexible tool (attachments with flags) to a unified review process (push to MozReview) is a shift from libraries to frameworks. It forces people to conform to the workflow which the framework assumes, and for people used to their own customized, library-assisted workflow, that's a very hard transition. Another example of a shift from libraries to frameworks is the bug triage process that was announced recently.

I think in both of these cases the end goal is desirable and worth working towards, but we should realize that it entails (by definition) making things less flexible and adaptable. In theory the only workflows that we eliminate are the "undesirable" ones, e.g. a triage process that drops bugs on the floor, or a review process that makes patch context hard to access. In practice, though, other workflows - both legitimate workflows currently being used and potential improved workflows get eliminated as well.

Of course, things aren't all as black-and-white as I might have made them seem. As always, the specific context/situation matters a lot, and it's always a tradeoff between different goals - in the end there's no one-size-fits-all and the decision is something that needs careful consideration.

Posted by smaug at 2016-01-31 16:44:35
One day people will start to remember that large number of the reviews aren't done using Splinter but the plain 'details' view, which is why the change to MozReview feels even harder.

But indeed a good point that MozReview decreases flexibility but hopefully improves the process. Though I assume we will need still plenty of the flexibility from Bugzilla to MozReview before the latter becomes the tool everyone uses. Even though I tend to say to patch authors that they should use whatever tool is easiest for them, there are still bad enough issues (from reviewer's point of view) in MozReview to prevent me to recommend its usage.
However, I'm optimistic. The number of bad issues isn't that high; couple of dataloss issues, silly review flag handling, missing some flags, and various UI glitches.
[ Reply to this ]
Posted by sfink at 2016-02-02 14:26:43
Much of software engineering is figuring out where flexibility is needed and where it gets in the way, because the costs can be high in either direction. Obviously, if some necessary flexibility is missing, you'll either be out of luck or need to go to heroic measures to hack in what you need. But if you have flexibility at the wrong place, then different users will use that flexibility differently, and everything downstream has to handle all possible uses. It can easily cause things to collapse under the combinatorial weight, by making writing correct code depend more on handling all of the different cases rather than focusing on the functionality of that individual piece.

Another example is inheritance vs composition. Inheritance is the framework way -- everything is provided except for the pieces you define or override for your specific use. But if you need a different part to be flexible, you're sunk; the base class just doesn't have that extension point. Composition allows using arbitrary helper objects, but then you have to generate a bunch of boilerplate to do the delegation and of course you need to handle completely random helper objects with arbitrary state dependence and temperaments.

With respect to mozreview, I think there is a large question of what flexibility is good and what is getting in our way. The flexibility to land something different from what was attached to a bug gets in the way of autoland. The flexibility of attaching arbitrarily-generated patches to bugs blocks expanded context, easy pulls, and better patch history.

Fundamentally, mozreview isn't that much more of a framework than bugzilla+splinter. MR will grow its own flexibility, alternative workflows, and automation APIs.
[ Reply to this ]
Posted by stak at 2016-02-11 06:21:51
Thanks for this well-articulated response!
[ Reply to this ]
Name:
Comment:
Allowed expansions in comments/replies: [i]italic[/i], [u]underline[/u], [b]bold[/b], [code]code[/code], [sub]subscript[/sub], [sup]superscript[/sup], [url=http://some.url]linked text[/url]
Human verification: Sum of fifty and fifteen =
 
 
(c) Kartikaya Gupta, 2004-2024. User comments owned by their respective posters. All rights reserved.
You are accessing this website via IPv4. Consider upgrading to IPv6!