Slashdot Mirror
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."
Is this chaotic release schedule supposed to be more attractive?
-V-
Who can decide a priori? Nobody.
-Sartre
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
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.
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.
#fuckbeta #iamslashdot #dicemustdie
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.
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.
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.
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.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
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.
There are 1.1... kinds of people.
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.
My blog
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.
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.
This is my sig.
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).
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?
You can't handle the truth.