Stop Beating the Lizard!
Pages: 1, 2
Reuse and modularization
Most of us talk about reuse and the importance of application modularization, but the Mozilla team walked the talk, and followed through on the principles of application design that we've been pushing for the last ten years.
After all, Mozilla, the platform, is nothing more than a set of reusable components, all of which were necessary for the development of Mozilla, the browser. A side benefit is that the same components can be used for other applications.
The one problem with reusability -- and the number one reason we keep coding and re-coding the same old functionality over and over again -- is that creating an application consisting of reusable components can sometimes slow the first release of the application. In these cases, the long-term benefits of this approach aren't realized until a later time, such as when new releases of the application are created.
Developers of large applications have long faced this early cost/later payoff issue with corporate managers and bean counters, and it's only with the second or even third release of the application, or releases of other applications, that the benefits of creating reusable code become apparent. In the beginning, though, the road to reuse is all uphill.
With Mozilla, you don't have to wait for the second release to see a payoff with its component-based architecture.
Returning to XUL again, it's true that the Mozilla developers could have hard coded a user interface instead of first creating XUL and then using XUL widgets to create the interface. The interface may have been finished a bit sooner (or may not, hard to say). However, any architectural change in Mozilla would then result in a recoding effort. With XUL, all that happens is some XML tweaking.
So when an architectural decision was made to alter the RDF/template processing, the Mozilla developers responsible for necessary browser elements such as the preferences dialog or the sidebar didn't have to recode their application pieces -- they modified the XML instead.
Recode the application interface versus tweak some XML: Do the math.
Reusable components aren't the only side benefit we'll get out of Mozilla. The project management techniques used to manage the Mozilla effort are also worth a closer look.
New project management paradigms
Personally, I wouldn't want to manage an open source project. The team members may or may not be employees, may or may not live in the same geographical area or time zone, and most likely have decidedly different interpretations of how the development process should occur.
I'd rather visit my dentist.
Mozilla is a complex application -- all browsers that appeal to web developers needing something more than a layout engine that processes HTML are, by necessity, complex.
Because the application is complex, and based in open source, the Mozilla team had to create new project management paradigms to control the code development process. Guess what? You can actually benefit from the lessons learned from this process in your own application development environment.
Consider this: A key factor of Mozilla development has been to break the application into manageable modules and assign ownership of these modules to small groups of people that are empowered to do what's necessary to create their modules, within the overall application architecture. If new functionality is wanted, a new module is created and isolated in such a way that if the functionality isn't finished, it doesn't get included in the Mozilla release. More importantly, it doesn't hold up the release.
To make this process work, much of the team communication is also in the open: in bug reports found in Bugzilla (a bug reporting/ tracking system you can download and use for your own development efforts), in status updates at the Mozilla site, and on newsgroups focused on each of the modules. This openness actually leads to some interesting results at times.
Earlier I mentioned that I was a Mozilla outsider. Well, this isn't entirely true.
When I tested my little XUL-based application with milestone release M16 and found my TOC wouldn't work, I checked with the Mozilla RDF newsgroup and found that the RDF processing had changed. Chris Waterson, a Mozilla/Navigator 6.0 developer who works on the RDF/template module, directed me to a document on how the new template process worked.
After reviewing the document, I asked Chris if he had any documentation or examples on nested content. Within a day, Chris added an example and a document page on how to implement nested content with the templates.
Chris helped me directly, but I actually worked within the Mozilla effort, indirectly, by asking a question that led to additional documentation that will help other developers.
How about that -- I was empowered.
Now, if I had asked Chris to change the template processing back, he would have said no, as this would violate the application architecture. My empowerment was checked within reasonable bounds.
The architecture constrained/modular project management approach worked, and worked well. Now, when was the last time you could say that about any large application project you were on?
Look beyond the box
There's more to the Lizard then meets the eye, but you have to take a look beyond the box -- or should I say browser?
Because much of the Mozilla effort's project management has been in the open, we can learn from this effort, and even apply many of the management techniques to our own efforts.
As just one example, if you work for a large shop, consider using internal newsgroups as a way for your own architecture teams to communicate with other developers -- this approach does work.
If nothing else, you can download and use Bugzilla, a sophisticated, free, bug tracking and reporting system.
As for the Mozilla platform: Take a moment to appreciate that the Mozilla development team has only been following the programming practices we've all been pushing for the last decade, and that the reusable component-based architecture is one we can all benefit from.
It's a better use of your time than beating the Lizard.
Shelley Powers has been working with, and writing about, web technologies--from the first release of JavaScript to the latest graphics and design tools--for more than 12 years. Her recent O'Reilly books have covered the semantic web, Ajax, JavaScript, and web graphics.
Also Featured This Week
Mozilla is Not Netscape (and Other True Facts)
Infinite Extensibililty with XBL
Discuss this article in the O'Reilly Network Browsers Forum.
Return to the Mozilla DevCenter.
