Forgot your password?
typodupeerror
Mozilla Programming

Mozilla Tries New "Lorentz" Dev Model 126

Posted by ScuttleMonkey
from the does-it-provide-synergistic-roi dept.
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."
This discussion has been archived. No new comments can be posted.

Mozilla Tries New "Lorentz" Dev Model

Comments Filter:
  • by Vornzog (409419) on Monday January 25, 2010 @12:52PM (#30892998)

    Is this chaotic release schedule supposed to be more attractive?

  • by Anonymous Coward

    Can I use the theory of special relativity to get out of missed deadlines? Sure, we are way behind in this frame of reference. But as viewed from a different frame of reference traveling near the speed of light relative to us we shipped yesterday!

  • by oldhack (1037484)
    God forbids if a name should suggest something of substance.
  • with lean methods?

    Where have I heard this before? [dilbert.com]

  • by Anonymous Coward on Monday January 25, 2010 @01:03PM (#30893134)

    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

    • by daveime (1253762)

      And there was me thinking it was named after EVE T1 salvagable materials ... looking foward to the "Burned Logic Circuit" version ... oh, wait, maybe we've already had that one, it makes your RAM fry from overuse.

  • Management has dubbed the new scheme - Lorentz of Arabia!

    Thank you, thank you, I'll be here all week! Try the lamb!
  • Scheduling (Score:5, Funny)

    by jpmorgan (517966) on Monday January 25, 2010 @01:04PM (#30893160) Homepage

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

      • by jpmorgan (517966)

        That depends entirely on how you define mass. Invariant mass doesn't change. Relativistic mass, (i.e., an object's resistance to deflection in spacetime), does.

        But at the macroscopic level invariant mass is a convenient fiction, unless you're dealing with something at absolute zero. If not then guess what: the invariant mass includes the object's heat expressed in kinetic energy.

        • "Invariant mass doesn't change."

          Uhhh... that *might* explain why they chose such a flabbergasting adjective... "invariant"!

    • I think you'll find that it is the otherway around: release dates will get a lot harder to hit because less time appears to pass for the fast moving developers compared to the rest of the planet. Also mass (not weight!) is an invariant quantity so there will be no change. Yes I know that a lot of people often think that the mass increases but it does not the 'gamma' factor in momentum comes from the velocity NOT from the mass which is why things like "F=gamma ma" do not work.
  • Development cycles (Score:5, Insightful)

    by girlintraining (1395911) on Monday January 25, 2010 @01:08PM (#30893208)

    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 (Score:5, Interesting)

    by threemile (215603) on Monday January 25, 2010 @01:09PM (#30893214)
    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: (Score:3, Interesting)

      by weicco (645927)

      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 dram

      • by threemile (215603)
        I wouldn't throw your article out - we certainly didn't disprove it as a methodology, but there are some business impacts that need to be planned for ahead of time.
    • by T.E.D. (34228)
      Wait...Yahoo! had products?
  • by Hurricane78 (562437) <deleted@slashd o t .org> on Monday January 25, 2010 @01:25PM (#30893466)

    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. :/

    • I thought everybody knew that and had switched to the spiral model a loong time ago.

      Hence the popularity of the term, "Project Death Spiral".

    • by tjstork (137384) <todd@bandrowsky.gmail@com> on Monday January 25, 2010 @02:14PM (#30894072) Homepage Journal

      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.

      • by Kjella (173770) on Monday January 25, 2010 @04:57PM (#30896580) Homepage

        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.

      • by T.E.D. (34228)

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

        Which has been a horrible downgrade from the waterfall days, when every one of their projects was over budget, underperforming, and late...but we all got "Cost+" contracts for them.

    • by PmanAce (1679902)
      "Hell, the whole game industry uses it. (As far as I know.)" Well I can confirm that my work uses agile, and we have been voted in the top 5 best studios in the world according to Game Informer.
    • Re: (Score:3, Insightful)

      by BitZtream (692029)

      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.

    • "The waterfall model is horrible for big projects."

      Given that the waterfall model was merely a straw-man, it's best not to use it for anything.

    • Re: (Score:3, Funny)

      by Angst Badger (8636)

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

    • Re: (Score:3, Insightful)

      by Doomdark (136619)
      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

    • Re: (Score:3, Informative)

      by Alef (605149)

      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.

      • "spaghetti code is absolutely not accepted"

        Yeah, of course not. And then, failing at a sprint goals is absolutly not accepted either (not at least by managment, which is all that matters). Do you know what happens when those two "absolutes" collide?

        "High quality code is imperative to maintain a successful product in the long run"

        And doing what needs to be done to reach the short run goals is imperative to get this week's paycheck. Again, do you know what happens when those two "imperatives" collide?

        "meth

        • by Alef (605149)

          I agree with you that nothing is as important for success as a skilled workforce, althought this is not limited to management. I would also argue that, in practice, skilled people will work in a similar way regardless of what methodology you put them in.

          However, that said, there still are differences between methodologies that are worth considering. Since we were talking about Scrum; one it it's most important aspects is not so much to dictate how you should work, but rather to provide tools and processes f

          • by spells (203251)

            Also, it is the Scrum Masters job to shield the team from pressure from higher management. Stakeholders are allowed to (and must) prioritise tasks, but the influence should end there

            In my experience, people at the level of a Scrum Master may have the responsibility to shield the team but they rarely have the authority. If the Scrum Master, or even a level higher, is unable to deliver to management's expectations, don't believe management is meeting to decide how they failed or how to replace themselves.

            • "In my experience, people at the level of a Scrum Master may have the responsibility to shield the team but they rarely have the authority."

              You stole the words from my mouth.

            • by Alef (605149)
              If Scrum is not understood and fully endorsed by the entire organisation, including higher management, it is doomed to fail. I agree this is a common problem, but the problem is not really with the methodology as such.
              • "If Scrum is not understood and fully endorsed by the entire organisation, including higher management, it is doomed to fail."

                It's doomed to fail, then.

                "I agree this is a common problem, but the problem is not really with the methodology as such."

                Yes. And communism failing because it doesn't take into account that people is greedy is not a problem with the ideology itself.

                *Any* policy that requieres endorsing from a whole organisation, each part of which has their own petty, sometimes colliding, objectives

  • All deployments end with "Doh!" and are fixed and redeployed.
  • by Rui Lopes (599077)
    I'm sorry, but *every* UI-centric application development model should follow any flavour of User Centred Design [wikipedia.org].
  • I much prefer the "someone just please code the damn thing" model.

  • I think a typical yet reasonable school of thought is that the best model depends on the characteristics of the project. Some projects are very fluid and some projects are very constrained. Designing the next cool iPhone game versus programming a perfect clone of last month's cool iPhone game.

When I left you, I was but the pupil. Now, I am the master. - Darth Vader

Working...