Revisiting how we build Firefox

We intend to move Firefox away from XUL and XBL, but the discussion of how to do that is in the early stages. There are a ton of unanswered questions: what technologies/best practices for web development should we adopt in its place? How does this affect add-on developers? Is there space for a native-code main-window on desktop like we have on Android? How much time should we spend on this vs. other quality issues? What unanswered questions have we not asked yet?

This clearly isn’t a small endeavour, but the rationale given seems sound to me.

Because starting from scratch is rarely a good choice – it sounds appealing, but it takes huge resources to achieve, and still ends up taking far longer than expected. And in the meantime, your existing product is being neglected, and you sink into oblivion…

Incidentally, Firefox isn’t a rewrite of Mozilla code – it was just a new shell around the same code. You’re probably thinking of the original Mozilla browser, which was a complete rewrite of the old Netscape code. The delays in getting a working release were at least a contributor to the death of Netscape…

As for IE->Edge, that’s not a complete rewrite either. As far as I can tell, “Edge” is just a new UI on top of the same rendering engine as IE11 used – they’ve dropped a lot of the legacy support modes, but there’s not much new about it.

I didn’t mean start COMPLETELY over, but do what Microsoft did with IE and Edge – bring over all the old parts to the new project that aren’t legacy and leave the old cruft behind, instead of trying to retrofit a new UI engine into the old code base.

Yeah, pretty much. There *are* cases where the “rewrite from scratch” approach has been successful – but there are a *lot* more cases where it’s been an unmitigated disaster that’s destroyed the company that did it. Evolutionary change is more painful, but also much more successful.

Because of this ‘cloud’ thing developers and operators from companies wanted to stop depending on single machines and want to get the benefits of auto-scaling.

These services are a lot smaller. They combine at least part of the unix philosophy (small specialized programs) with some of the ideas from for example the mostly failed Service Orriented Architectures from the enterprise Java world.

Every microservice is usually stateless so it can easily be scaled. With a seperate data store per microservice.

The seperation that these microservices create usually in large companies also fall along the boundries of the company (deparments and so on).

If you make small programs you can much more easily rewrite them. And this actually happens.

Even Mozilla is only writing it’s engine (rendering of HTML pages). Not the Javascript engine or the networking code or the interface, etc.

And it’s true, alot of legacy code/design holds back better code/design. We continue to use it because it’s “good enough”. And incrementally evolving software to cope with new demands is also “good enough”. But when the goals and demands change over time the “evolution” approach forces us to take a different path than what would have been designed with those goals in mind. The resulting compromise between new goals and legacy codebases really can be hideous and complex as anybody who’s been in the industry for any length of time should be able to attest to.

The thing is, a project manager looks at it this way, and the rewrite is almost always more involved:

X man-hours for upgrade.

Y man-hours for rewrite.

Y>>X

Yet as years drag on and X is aggregated, eventually the sum of X will exceed Y, such that it would have made sense to commit to Y hours for a rewrite rather than maintaining a legacy codebase. But the thing is you need a rather long outlook, focusing on short term results usually takes a rewrite out of the cards, for better or worse.

I have enough experience with legacy code to know that maintaining it can be far more complicated and time consuming then any of the project backers want to admit.

I also have enough experience with new code to know that if it’s not done correctly, or communication channels are poor between end users and developers, then that will amplify problems with Y. And unfortunately the project managers themselves (as middlemen) are often the cause of communications problems. They abstract the end user for developers, and they abstract the developers for end users. 30 minutes worth of actual developer work can become days and days of expensive multi-party conference calls.

Of course not every place is like this, it really depends on the business environment. In my opinion though, when there’s a top-heavy structure with lots of middle managers, it strongly favors minimizing changes.

The catch is that if you focus on the long term and neglect the short, you usually don’t last long enough for the long term to matter.

To me, “a catch” implies something unexpected – as in “what’s the catch?” But if you have reasonable expectations and remain nibble, then ditching an old problematic code base can pay off. Mind you a rewrite isn’t necessarily the right choice, it depends.

I’ve subcontracted for clients who still use IBM mainframes, which is the ultimate legacy code. Sometimes it’s good enough. But other times the owners need extremely complex roundabout solutions to make it work with more modern systems or are getting grief from the users on limitations that are practically impossible to fix without a rewrite. These are the times when a rewrite can be favorable.

However I think corporate culture itself can be more important than whether it makes sense on paper. Companies with nibble teams and low political resistance will be able to achieve turnaround (and savings) far quicker than those entrenched with bureaucracy. Because lets face it, when corporate politics are involved, not everyone will be on board and some will prefer that the replacement fails. Project managers with cushy jobs will likely have better retirement prospects if they play along with the status quo and don’t try to change things (for better or worse).

The really fun projects are those that already at the end of the first development period requirements change significantly. Preferable a short time before the deadline. Those are the best. 😉

Hmm, masochistic or sarcastic

Yea changes do happen. There have even been some occasions when I knew beforehand that we were going down the wrong track (ie not what the customer would want), but got overridden by the PM. Low and behold, the customer comes back and asks us to re-implement something the way I thought it should have been done from the beginning.

I’ve learned to raise my concerns in detail up front, but then play along with whatever the PM says, this way I’m not overstepping my bounds but at the same time I can at least say that I did bring it up.

I like this development which sometimes goes along with this devops trend.

Basically: find something we can measure and give a team of people a task to improve those meaurements and let them do it any way they see fit.

Like: change the design of the website to get more people to sign up for our services. This is something you can measure because you know the number of sign ups per day. Or maybe it means: the website loads to slow or doesn’t work on mobile or whatever. Who knows, let them figure it out and solve the problem.

This could mean things like: do A/B testing on the website to see what design works better, etc. etc.

What this also means is: there is no PM and all that stuff. Just people trying to get shit done and getting results for clear business goals.

I also like that approach, it’s more fun to have a longer leash. My inclination is that worker competency & motivation matter much more than management for our kind of work (aka management should mostly stay out of the way). However I was not able to find a study showing a correlation between management strictness and productivity.

My gut reaction to talk of tossing the basis of a platform out like this is skepticism. It is rarely a good idea to do so rather than fixing the platform.

That said one time I spent a few months diving into mozilla code to develop a native extension and that was by far the worst coding experience of my life (and that includes spending 4 months working on a 80kloc web app written in VB6 and managed by Visual Sourcesafe)..

My gut reaction to talk of tossing the basis of a platform out like this is skepticism. It is rarely a good idea to do so rather than fixing the platform.

Which is why the Mozilla folk don’t seem to be talking about “rewrite the whole thing”. The mailing-list post is kind of vague, but I assume this ties in with past discussions and experiments around using the HTML engine to render the Firefox shell, instead of maintaining the separate XUL engine and related pieces.

So, what I’d expect to come out of this is that they gradually rewrite parts of the existing UI – maybe starting with the relatively-separate pieces like the developer tools, and preferences, and add-on manager, then the main browser shell itself. Eventually, they’ll be left with a system that doesn’t use XUL/XBM at all, and they’ll be able to delete them.

Folks said that Pocket should have been a bundled add-on that could have been more easily removed entirely from the browser. We tend to agree with that, and fixing that for Pocket and any future partner integrations is one concrete piece of engineering work we need to get done. Pocket was also given first billing on the main screen, and that may not be a scalable solution. Weâ€™re going to need to figure out how to best surface these things in our UI.

If it’s just stuff packaged as bundled add ons that could be disable with a check box, then who cares?