
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">The intended audience for this post is ‘all’, not just Benjamin. Benjamin, thanks for creating a place where I can share this.</div><div class=""><br class=""></div><div class="">I think Benjamin’s first point that swiftly attempts to validate the assumption that the core limiting factor is in fact the modularity and module boundaries in our codebase is comparing apples to oranges by offsetting process against code architecture.</div><div class="">I think we’re looking for a problem that presumably causes our apparent inability to go faster in the wrong area.</div><div class="">In that vein I was very pleased with Richard Newman’s post to this thread; you should read it!</div><div class=""><br class=""></div><div class="">Before I start, I’d like to point out that our current WebExtensions model is mostly comprised of interfacing with our lower level JS modules, adding a layer of indirection that we most often don’t need in frontend code that builds the browser.</div><div class=""><br class=""></div><div class="">Our current development model skews big code refactors and favours small, incremental iterations that extend the existing code a bit where it fits best, adds a unit test and call it a day.</div><div class="">I hear more and more noises, coming from various directions (product, UX, devtools, addon-sdk, WebExtensions, Servo, B2G, etc.) that are all variations of “Hey, what if we could rewrite Firefox to get rid of all this old, complicated crap?”</div><div class="">This should not be taken seriously. At least, not in the sense that we should actually _try_ to rewrite Firefox in its entirety. It’s in fact a big fat billboard poster on the wall in front of you that says: “This culture sucks, I don’t feel empowered enough to accomplish anything of sufficient value here!”, “Something needs to change! I don’t know what exactly, so rewriting the entire thing is what I can come up with right now!” and “Halp!”</div><div class="">If you read between the lines and talk to all developers - not just the ones who are loud - you’ll have to notice that the current cultural setting is not enabling us to go faster at all.</div><div class="">Rewriting the browser: not faster. Making small changes with le unit test attached: not faster. Adding a layer on top of existing modules: not faster.</div><div class="">What’s missing is that we are not able to _sell_ code refactoring, thus we’re almost never doing it, unless it’s absolutely necessary. Like when Electrolysis happened. (And moving to multiple content processes is going to yield even more refactoring and modularisation of code into a more modern style.) And if we’re not doing it enough, we don’t get a chance to become really good at it, either.</div><div class="">We’re scared to make changes other than small ones, because of their high(er) potential to introduce regressions. Regressions have a bad name, because they cause more work, keep developers busy whilst the calendar says they’re supposed to be working on something else. Managers hate them, because one cannot plan ahead whilst all these issues take priority over all other (future) work. Release Engineering will bounce your uplift requests and push for more strictness. I’d like to call them side-effects, instead, because they’re very valuable:</div><div class=""> * It shows our community from their best and shiniest angle: reporting bugs! Why focus on trying to move this colossus of a body to something that they don’t want to do (write code), but instead capitalise on their oft-emerging strength (file bugs) to feel a part of the community and help the Fox forward?</div><div class=""> * They uncover parts of the codebase that are, yes, not covered by unit tests.</div><div class=""> * When fixed, they are _always_ verified by our community members who filed the bug, showing yet another shiny angle from them.</div><div class=""><br class=""></div><div class="">But even though side-effects have these fine advantages, we wary them, because they’re not part of the process. If you don’t have a good method of dealing with side-effects, good luck pulling a code refactor through without a bruise or two.</div><div class="">But fortunately for us, process has a tendency to evolve when the need arises (again, look at e10s), so the only thing stopping us from moving forward and faster is our inability to sell code refactors.</div><div class="">Why would we need to remove #ifdef’s in our CSS and JS code _right now_? Why do we need to split browser.js or nsSearchService.js up into modules _right now_? It’s never a priority, until the collective frustration - not of the developers _working on_ it, but of all the developers having to _read_ it - reaches the boiling point. We seem to getting closer nowadays, is the feeling I get when I occasionally put out my temperature gauge.</div><div class="">Of course, there are strict rules attached to doing a code refactor of reasonable size and that’s where senior mentorship (note that I’m not using the prefix _leader_ at all) comes in to guide these projects and teams in the right direction with tips and best practices or even contributions. It’s also their responsibility to coordinate efforts and make sure there’s a certain gradual approach to refactoring the frontend, like not running two tracks at the same time.</div><div class=""><br class=""></div><div class="">Another, closely related defect that’s highly likely to have an effect on our inability to move faster is our culture of module ownership. I’m advocating for a complete removal of that concept. The word ‘owner’ has too many connotations that confuse the heck out of people: “Do you own that code like you own a house? What does that mean? Do I need to ask your permission if I want to step on your lawn?“</div><div class="">Instead, the current module ‘owners’ list should be reset to being ‘candidate reviewers’ only; people who have enough understanding of that area of functionality that they’re able to make qualitative judgments on contributions, are available for any question a contributor might have and willingly partake in triage sessions. (The fact that developers do triage in the first place is an interesting subject to me, but out of scope here.)</div><div class="">There is always someone who must _own_ the project. But in that context, the word simply fits. This person must assure that there are always enough candidate reviewers available for the different functional areas.</div><div class=""><br class=""></div><div class="">When you think and talk about modules and architecture, I think that simple faith in the fact that a smart, top-notch developer, like we all are of course, has a natural tendency to take the modern approach to writing new code. I mean, when you look at the most recently written slabs of code, I see the latest ECMAScript features, ReactJS, async-await style control flows, less LOC per module and smaller function bodies. Technically, we ought to be able to refactor very well; it shows.</div><div class=""><br class=""></div><div class="">I think that I’m at a word count currently that’s more than enough for now. I did not permit myself the luxury of a proof-read, so please forgive the broken English if it’s there. Please feel free to reach out if you feel I should clarify/ say more!</div></div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Mike.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 06 Oct 2016, at 17:08, Benjamin Smedberg <<a href="mailto:benjamin@smedbergs.us" class="">benjamin@smedbergs.us</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">I spent a week writing a thing about modularity, webextensions, and going faster. I think it's important for us to decide the module structure of our code especially as we start shipping independent modules/going faster. And I believe that having better module structure, boundaries, and documentation is critical to our teams being more agile and also attracting contributors to the project.<br class=""><br class=""><a href="http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-webextensions/" class="">http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-webextensions/</a><br class=""></div><div class=""><br class="">I personally think that we should double down on WebExtensions as a model and start using that for large parts of Firefox. But Andy McKay and Rob Helper had some good counter-thoughts and I've asked them to post here to elaborate. <br class=""><br class=""></div>In the post I asked everyone to send followups to firefox-dev, so I wanted to start a thread here to collect responses. Over the next months I'd like this to turn into a firm decision about how we're going to build system addons; but I'd like to start by seeing what feedback people have and even whether I've framed the problem correctly.<br class=""><br class=""></div>--BDS<br class=""></div></div>

_______________________________________________<br class="">firefox-dev mailing list<br class=""><a href="mailto:firefox-dev@mozilla.org" class="">firefox-dev@mozilla.org</a><br class="">https://mail.mozilla.org/listinfo/firefox-dev<br class=""></div></blockquote></div><br class=""></body></html>