Mozilla Tries New "Lorentz" Dev Model

With the recent release of Firefox 3.6, Mozilla has also decided to try out a new development model dubbed "Lorentz." A blend of both Agile and more traditional "waterfall" development models, the new methodology aims to deliver new features much more quickly while still maintaining backwards compatibility, security, and overall quality. Only time will tell if this is effective, or just another management fad. "If the new approach sounds familiar, that's because Unix and Linux development has attempted similar kinds of release variations for iterating new features while maintaining backwards compatibility. HP-UX, for example, is currently on its HP-UX 11iv3 release, which receives updates several times a year that add incremental new functionality. The Linux 2.6.x kernel gets new releases approximately every three months, which include new features as well."

Comments

Chaotic releases?

[Vornzog]

Is this chaotic release schedule supposed to be more attractive?

Re:Chaotic releases?

[Nerdfest]

Releasing when a feature is ready sounds both chaotic and reasonable. Chaotic is not neccessarily bad.

Re:Chaotic releases?

[TheLink]

Was that a butterfly wooshing by? ;)

Re:Chaotic releases?

[Eudial]

Again, I request a "+1 Badum-tish"

Re:Chaotic releases?

[morgan_greywolf]

Releasing when a feature is ready sounds both chaotic and reasonable. Chaotic is not neccessarily bad.

Three words: Duke Nukem Forever.

*ducking*

Re:Chaotic releases?

[oGMo]

So what you're saying is that this model is chaotic good instead of chaotic evil ...

Re:Chaotic releases?

[luserSPAZ]

http://en.wikipedia.org/wiki/Lorentz_National_Park

Firefox codenames are always park names nowadays. This park happens to be in Indonesia, which (AFAIK) is the first country to pass 50% Firefox marketshare.

The branch is Lorentz, not the development model

[Anonymous Coward]

All of the Firefox branches are named after national parks... the name has nothing to do with the development model.

http://en.wikipedia.org/wiki/Lorentz_National_Park

And they are moving their servers to Amman

[BancBoy]

Management has dubbed the new scheme - Lorentz of Arabia!

Thank you, thank you, I'll be here all week! Try the lamb!

Scheduling

[jpmorgan]

Plus, with the "Lorentz" transformation, time dilation makes it a lot easier to hit release dates. But there has been some concern over the developers' sudden weight gain.

Development cycles

[girlintraining]

the new methodology aims to deliver new features much more quickly while still maintaining backwards compatibility, security, and overall quality.

A style of management is only as good as its manager(s). We've had many, many methods of improving all three of those but as an industry we routinely and repeatedly turn it down for most applications over cost considerations. A new hybrid model of development won't change this -- continual pressure from inside the organization will eventually subvert any gains at the process level. Senior level management has to push this from the start -- only then would this or any other kind of methodology have a chance at achieving its goals.

Waterscrum

[threemile]

At Yahoo! we tried this on a few projects and ended up calling it waterscrum. Wanting the dev flexibility of agile and the (perceived) business certainty of waterfall at the same time isn't really possible when it's not understood that the dev methodology has impacts outside of the tech organization. If you're doing agile dev, the marketing materials, sales collateral, etc are much more difficult to write and lock down when you're looking to make a splash in the market. For agile to work the entire company needs to be okay with some level of uncertainty, or at least understand that for major market releases you still need to plan a date far in advance. Just because you're launching code doesn't mean you're launching a product, and getting materials locked down is harder to do when, by definition, changes happen more frequently.

Re:Waterscrum

[weicco]

Dang! I thought I had perfect idea how to mix waterfall model with agile development. I started writing an article about it some months ago but can't get myself to finish it.

Idea was basically that when you start a project you must know at least something about what problem the project tries to solve and there's your goal. When the goal is at least somewhat clear you write requirements analysis and architectural specification. You can always come back to arch-spec but you have to understand that making dramatic changes means that costs go up and well as development time.

Next thing is to define interfaces. If your application has many different modules you need to define how those modules interact with each other. This helps in next step if there's going to be changes especially inside the modules.

After this we start agile "steps". You define one step or iteration. You write functional spec which sets to the goal that particural step. You can change func-spec when ever there's a need. Changes in the func-spec doesn't necessarily raise costs and development time much, not at least as much as changing arch-spec because changes touches only (hopefully) this one step.

Then I figured out that TDD and CI would be perfect models for this kind of development. With TDD and CI you at least have automatic regression tests which can (and will) be run every time something's changed. When one step is completed and fully tested you go to the next step and so on.

When all the steps are done you check that program meets every requirement and proceed to full system test in a duplicated production environment. If that goes OK then it's time to roll it to production and start sending bills.

But if you have already tested this and found out it doesn't work I think I save myself some time and send my half-baked artice to /dev/null :(

Re:No

[electrosoccertux]

The Linux 2.6 model sucks. 2.6, 2.8. 2.10, etc became 2.6.1, 2.6.2, 2.6.3... on short support cycles.

You, sir, do not seem to know the nightmare that maintaining separate kernels, and porting features and bugfixes back and forth, created.

Re:No

[Cyberax]

2.4/2.5 model sucks, because we have to wait years before features propagate to the stable mainline kernel. Or have to resort to backporting and vendor branches.

Oh god, the still use Waterfall?

[Hurricane78]

The waterfall model is horrible for big projects. I thought everybody knew that and had switched to the spiral model a loong time ago.
And now they add the only thing to it, that in even more horrible? Agile?? Or in other words: Spaghetti coding with the motto: “If perfect planning is impossible, maybe not planning at all will work.”
No, dammit! It’s just as bad.
Maybe that’s why they try to mix them both... To get to the actually healthy middle ground.

But still, it’s silly. We have a perfectly good spiral model. Hell, the whole game industry uses it. (As far as I know.) And it works great, even on those huge 5-year projects. (Notable exception that proves the rule: Duke Nukem Forever.)

Sorry, but that will result in a huge epic failure, and probably Firefox’s death.
Mark my words. :/

Re:Oh god, the still use Waterfall?

[BitZtream]

First sign a developer is shitty ...

He/She starts talking about 'which development model is better' and starts naming them.

Its the developer with the issue in your case, not the model.

Re:Oh god, the still use Waterfall?

[Angst Badger]

Oh, pfft. The thing that killed Duke Nukem Forever was the decision to implement it in Perl 6.

Re:Oh god, the still use Waterfall?

[Doomdark]

And now they add the only thing to it, that in even more horrible? Agile?? Or in other words: Spaghetti coding with the motto: “If perfect planning is impossible, maybe not planning at all will work.”

This is not meant as a flame, but I don't think you have a clue as to what Agile here means. Possibly because term has been abused a lot by people who just want to get rid of all processes -- nonetheless, agile does not mean "no process". Just a light-weight common-sense process that most mature developers would follow anyway.

It is also true that agile methodology is a meta thing ("abstract methodology"). So it is bit silly to argue about it, as opposed to concrete implementation thereof like Scrum. But I assume you were referring to class of methodologies, all of which allegedly would be just excuses of not thinking through anything. And that is a false statement.

Re:Oh god, the still use Waterfall?

[Alef]

And now they add the only thing to it, that in even more horrible? Agile?? Or in other words: Spaghetti coding with the motto: “If perfect planning is impossible, maybe not planning at all will work.”

It is obvious that you have never worked with a properly implemented agile process.

First of all, spaghetti code is absolutely not accepted. High quality code is imperative to maintain a successful product in the long run, and something methodologies such a Scrum explicitly declare as non-negotiable. In fact, one of the main points of Scrum is to try to eliminate stakeholders' influence over the quality--time trade-off.

And secondly: Of course you do planning when you work with Agile! It's just that you don't stipulate what will be achieved by a certain dead-line -- instead you estimate. And this is the only sensible thing to do. You cannot be more efficient than 100%, no matter how much you need to. If things take longer, then they were harder than you thought (and hence you try to make a better estimate the next time). You can reduce the scope of the task, or you can put in more hours for a temporary boost, but the map has to change if it differs from reality.

If you with "planning" mean writing specifications, then no, you don't write as much specifications. But that doesn't mean that you do not write any specifications at all. Again, common sense dictates the rule. Specify what you need to, but don't try to specify things just for the sake of it. That is pointless at best and usually detrimental.

Re:No

[Magic5Ball]

Mozilla have fallen into the classic trap of trying to expand its user base via increasing features, as opposed to keeping its user base by increasing quality.

We don't need new features directly in Firefox. Plugins do that. Remember that long ago the project made a conscious choice to take a performance hit to provide third-party access into the browser via the elaborate XUL and plugins frameworks, to minimize pushing code and features onto users who don't need them.

Re:No

[Anonymous Coward]

Why does the Linux community have so much trouble with it, while nobody else does?

FreeBSD, for instance, manages to have several major-number releases in use at any given time. FreeBSD 9.x is in development. FreeBSD 8.x is the recommended production release. But even FreeBSD 7.x is still supported. Not only that, FreeBSD manages to get out several point releases each year, in addition to a major release. But it has none of the problems you mention.

Maybe it's a maturity thing. The FreeBSD development community is made of very talented and very experienced developers who know that you shouldn't just throw patches and features around willy-nilly. The FreeBSD user community is also more mature, willing to wait a short while for a feature to become available through the natural release cycle.

Re:No

[morgan_greywolf]

You're both right. New features getting adding to the stable kernels have done much to reduce stability between kernel versions. So much so that distros have had to pick up the slack by introducing an increasing number of patches. Have you ever looked at the patchset list for Ubuntu? There have been like 17 different kernel patchlevels for Karmic Koala since it was released in October. That's more than one patchset a week, and each patchset can have anywhere from 1-10 patches.

E = mc^2 only for velocity ~= 0.

[FooAtWFU]

The "weight gain" is due to an abuse of the equations:

The equation Einstein came up with more than a century ago can be considered a degenerate form of the mass-energy-momentum relation for vanishing momentum. Einstein was very well aware of this, and in later papers repetitively stressed that his mass-energy equation is strictly limited to observers co-moving with the object under study. However, very, very few people seem to have paid attention to Einstein's warnings, nor to any of the more recent warnings. Even worse, the vast majority of authors of popular science books take great liberty in applying E=mc^2 to objects moving at speeds close to the speed of light, and then declare mass to increase with velocity in an attempt to recover consistency in what has become an incoherent mix of relativistic and Newtonian dynamics. Theoretical physicist Lev Okun refers to this practice as a "pedagogical virus". ..... What I consider truly amazing, is how few people are aware of the mass-energy-momentum relation.

-- What's Wrong with E=mc^2, The Hammock Physicist.

Our blogger then proceeds to draw a right triangle with sides E*v, E*c, and m*c^3. For velocities (v) of 0, E*c=m*c^3, or E=mc^2. Yay vectors.

Re:No

[Luke has no name]

I concur. The "Major.Minor.Bugfix" version scheme is much more informative than Linux's arbitrary "2.6.iteration" format. The 2.6 part doesn't even matter anymore.

Major number changes with breaks in back compatibility, changes in the direction of development, major new features/architecture, etc.

Minor number changes within Major number with new features but does not affect compatibility with same Major version. Do not take away features (e.g. no regressions)

Bugfix number changes within Minor number when no new features are added, code has simply changed or bugs fixed.

Re:No

[Magic5Ball]

The elegant solution to too much choice among plugins isn't to revamp the software development workflow, nor is it to load every conceivable feature into the default interface. (Assuming that the opposite were true, Firefox would ship with all 10,000 plugins loaded, which it does not.)

Since Firefox is starting to resemble an operating system anyway, it might be time for Firefox distributions, which default to a core consisting of functions expected of every browser, along with the small number of exceptional features/plugins/whatever which differentiate Firefox from everything else in a good way. (That would also give users tangible reasons to choose and stick with Firefox.) Otherwise, more features for the sake of more features leads to office productivity suites in which most users must download, install and load but will never use 95% of the available features.

Re:No

[diegocg]

It's not the waiting what sucks. What sucks is that the old development model was more unstable. For big projects linux with a lot of activity, long development cycles just don't work. You don't have releases, so users don't test it. Once you get out the first stable release, users notice that it's very buggy (but you still don't know all the bugs, because most users and distros are still not using it because it has too many bugs), and it takes a full year to get the codebase into a decent shape. That's what happened with Linux 2.6. They had been dropping thousands of LoC for a couple of years. Because it's a "unstable cycle", quality was not so important, the main tree was used as a repository for "work in progress" code, and even if it was important (which it isn't, even it there's a corporate policy that says that it must be) you can't measure the quality of the code, because the users are not using it.

The new model, in the other hand, allows new feaures in every release, but it's much easier to track regressions compared to the previous model. The new features are required to have some quality, they can't have serious bugs, maintainers must agree that they can be merged, and they only can be merged in the first two weeks of the 3 months development period. It allows to make progress faster, and at the same time bugginess is controlled more easily. Previously, you had a huge diff of several MB, users reporting that the huge diff was causing several bugs and regressions in their systems, and developers had to start debugging the alpha code they had written, and had not tested, two years ago. IMO, long term, it's much better for everybody. It's not surprising that FreeBSD and Solaris are using this model too, it makes sense for Mozilla to use it aswell.

Like Spiral Model is Good?

[tjstork]

The waterfall model is horrible for big projects. I thought everybody knew that and had switched to the spiral model a loong time ago.

The spiral model is utterly terrible. Since the DoD moved over to it, every one of their projects is over budget, underperforming, and late.

Agile isn't all that much better. The whole point of Agile is that you can have all of these changes... but you can get that with shorter release cycles, and its pretty easy to game Agile as much as any other model.

I think waterfall is probably still the best.

Re:Like Spiral Model is Good?

[Kjella]

Based on my experience so far I would say to do the technical structure with waterfall, and the functional structure with agile. What do I mean by that? Well, most of the time the customer doesn't really know what he wants, which is why blueprinting fails so miserably. But you can often at a technical level know what a customer wants. Let's for example say the customer wants drop down fields in an application. You know you'll need a storage backend (database?), UI front end (web app?), you need functions to manage the values, you need listing, sorting, filtering (single or multivalue?), security, audit logs and so on. You can design a ton of things by waterfall without actually knowing what drop downs the customer will want.

Agile promises to do that by refactoring which rarely happens because it's very likely to break things that were already working, despite the unit tests. They need the documentation from the original waterfall design, and they need the testing from the new waterfall design to ensure quality. One of the things I've noticed suffers most in agile is the documentation because there's an implicit belief that this will all change again, so people skimp on it even more than usual to document it when it's "final". The result is often that things are kludges made to extend things rather than actually going back to refactor, because people spent very little time thinking about a long term design in the first place.

Conversely, I have done quite a few implementation projects and in most the customer has only a list of specifications and no real idea how he'd like it to work. Creating a blueprint accurate enough that technical people could implement by and that the customer understands well enough what he's not going to say "well, that's not what I wanted" is like pulling teeth. And at the end of the day, different stakeholders will still have a different idea in their mind of what it's going to be. If you have a decent architecture, then you can do agile on top of that. Want this link to go there? Want to see these things? Can we get a checkbox there? Can you calculate that in a preview? Hopefully yes, but if it goes against the architecture it might need to go a longer waterfall process.

There's a balance here, on the one side you got expert systems that try to be ultraflexible in every direction but only ends up as an overcomplicated mess. On the other, you have the projects where nobody took five minutes to think "Am I trying to solve one special instance of a general issue here?". I've no idea if it'd only make a complete mess of two development methodologies, but I'd sure like to try it out sometime.

Re:No

[Anonymous Coward]

Patch levels don't start at 1 the day of release, they start the day they start working on the next branch. The kernel included in the installation CD was at patchset 14, the latest released one is 17 (However there were 2-3 updates that didn't change the patch level). And Lucid is already at -11 (see http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-meta/linux-meta_2.6.32.11.11/changelog and http://packages.ubuntu.com/lucid/linux-image).

Re:No

[Magic5Ball]

Mozilla Corporation's goals are substantially to do activities which bring in revenue, as with Microsoft. Mozilla's main vehicle for doing so is to package and distribute a browser through which income is generated via Google searches. To maximize revenues, they need to maximize both market share and usage of their browser.

The new focus, maximizing market share (quantity), could help, but not as much as a new strategy which maximizes both market share and usage (quality). Under those 30 MB or so of binaries, libraries and other stuff, I'm sure exists a small feature subset set which would give all Internet users a compelling reason to switch to and stick with Firefox, if that feature subset were promoted correctly.

Based on their list of "new features", http://www.mozilla.com/en-US/firefox/features/, they don't seen to know what makes Firefox special.

Private Browsing - "Surf the Web without leaving a single trace." Which inaccurately describes the functionality. Safari and Chrome can forget things in the browser, but the Firefox feature as stated requires third-party anonymising proxies or such.
Password Manager - "Remember site passwords without ever seeing a pop-up." - Most browsers have had features to remember form fields since the 1990s?
Awesome Bar - "Find the sites you love in seconds (and without having to remember clunky URLs)." This is better than bookmarks/favourites?
Super Speed - "View Web pages way faster, using less of your computer’s memory." OK.
Anti-Phishing & Anti-Malware - "Enjoy the most advanced protection against online bad guys." ... Using substantially the same database as IE and Chrome.
Session Restore - "Unexpected shutdown? Go back to exactly where you left off." Tires unexpectedly fall off? Can I have a browser that doesn't need to have this feature?
One-Click Bookmarking - "Bookmark, search and organize Web sites quickly and easily." It doesn't trouble me to click once or twice to bookmark something in any other browser, but OK...
Easy Customization - "Thousands of add-ons give you the freedom to make your browser your own." OK. But there's a handy guide to navigate those thousands, right?
Tabs - "Do more at once with tabs you can organize with the drag of a mouse." Like every other browser?
Personas - "Instantly change the look of your Firefox with thousands of easy-to-install themes." Instantly change the look of your windshield with thousands of ... No thanks. We got here without bringing MySpace all the way to the desktop. Also does not enhance the functionality of the browser.

We use the "Homer" Methodology...

[bodland]

All deployments end with "Doh!" and are fixed and redeployed.

Forced add-on updates

[roman_mir]

You know that it is silly, that every time a new version of FF comes out, every add-on author has to up the version on his code and resubmit to amo? Most of the changes from version to version of FF does not affect most addons at all and yet there is this whole thing with addons having to be resubmitted, wait in the queue for weeks and at the end the only change in the new version is the maxVersion tag in the installation rdf.

On the other hand there is now talk of completely changing the system of interfaces between addons and the browser. Who has time and interest to rewrite the same thing over and over again?

Re:Forced add-on updates

[luserSPAZ]

That's great, but there are lots of extensions that do in fact break. If users update to a new version of Firefox and their extensions don't work, or cause their browser to crash or otherwise malfunction (not a theoretical problem), they are not happy users.

The Jetpack project is working to create a stable (but admittedly more limited) API for extensions to use to make it possible to sidestep this problem.

the universe is predjudiced!

[Thud457]

Obviously, DNF, if completed, would have had some sort of feature that generated Higgs bosons.

Re:No

[msclrhd]

How do you know that Mozilla are not improving quality? If you pay attention, Mozilla are improving the quality of the codebase (memory consumption/leak fixes, crash fixes, etc.).

And while plugins do add some features, what about HTML5 support? Support for SMIL animations in SVG? Out of process plug-ins? Better JavaScript performance? Support for additional emerging and evolving standards? Better OS integration on Windows, Mac and Linux? Hardware-accelerated page rendering? WebGL support? And much more.

Re:No

[dylan_-]

Session Restore - "Unexpected shutdown? Go back to exactly where you left off." Tires unexpectedly fall off? Can I have a browser that doesn't need to have this feature?

Yes, Firefox 3 will include a Virtual UPS.