This post originated from an RSS feed registered with .NET Buzz by Darrell Norton. Original Post: The Mozilla Development Process Feed Title: Darrell Norton's Blog Feed URL: /error.htm?aspxerrorpath=/blogs/darrell.norton/Rss.aspx Feed Description: Agile Software Development: Scrum, XP, et al with .NET Latest .NET Buzz Posts Latest .NET Buzz Posts by Darrell Norton Latest Posts From Darrell Norton's Blog

A lot has been made about how great the Firefox browser is, and how it’s finally better than IE. One thing that has been overlooked, though, is the process Mozilla is using to develop software. Sure, everyone laughed when Joel Spolsky called the decision to rewrite the code base from scratch stupid, but nobody has picked up on how well they are doing now. Firefox is currently available in 24 languages with 7 more on the way on 10 different operating systems (flavors of Windows, Mac, and Linux) and is setup to work on 32 and 64-bit systems.

The secret is right on Mozilla’s web site, in the Hacking Mozilla site and in the Introduction To Hacking Mozilla. There are strict guidelines on writing portable C++ to keep Mozilla compiling on all those different platforms. There is a coding style guide that is enforced by code reviews. And the Mozilla roadmap paints a clear direction for the future of the project, as well as discussing how past events have led to current decisions (gee, I wish I had that on all my projects!).

All code is reviewed before being committed to source code control, usually twice. First, the module owner has to approve the code, or else the code doesn’t get in. There are very clear rules about check-ins and there is a checklist for code reviews. The existence of module owners and peers, people to whom the module owner has delegated authority to, also implies that there is clear ownership of code through the modules. Then most code is reviewed again by a “super-reviewer.” The neat thing about a super-reviewer is that they earned their reputation by continually making good decisions on whether code is good or bad based on the track record of check-ins.

Then comes quality assurance. There is a pre-check-in test list, full smoke tests including performance testing, and detailed accounting that makes everyone who checks in code “on the hook.” Being on the hook means that you are around to make fixes should the build break. Chris Yeh writes,

“After checking-in, you watch Tinderbox until your check-ins clear. You do not go home. You do not sleep. You do not log out or experiment with drugs. You do not become unavailable.”

Builds are watched over by a different sheriff every day. The sheriff watches over the builds, opens or closes the tree for various reasons, fixes blockers, and hunts down whoever broke a build to get it fixed as quickly as possible.