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

Re:Chaotic releases?

[Nerdfest]

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

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

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

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.