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."
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 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.
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.