Deliberacy

The Firefox community is kicking ass. We just worked through our first Aurora merge as part of our new rapid release process and in less than 6 weeks, the next train leaves the station. We are rewriting the way we build software and we are doing it fast.

We’re succeeding because we’re acting deliberately. We’re doing it on purpose. We know what we need our release process to do and we’re building forward from that, instead of shooting first and calling whatever we hit the target.

I’m glad that we’re being deliberate about how we build Firefox. We need to be deliberate about what we build, too. I’ll tell you how I think that should go, after a brief digression on how it has gone up until now.

(If you have no time for that, deb’s written a more concise introduction.)

Prehistory: Bugs

Historically, if you wanted to get a feature built, you filed a bug. Maybe you started a newsgroup thread, or an irc conversation but it wasn’t real until there was a bug. This is a great instinct. It makes the work concrete, it lets people opt in to tracking its progress, and it makes Bugzilla into a single source of truth about active work in the project.

Recent History: Prioritization

Bugs are good for tracking atomic pieces of work, but they are not good for overall project direction. As Mozilla grows, with more going on at once, we hit contention for scarce resources like code review, UX support, even permission to land at all, late in cycle.

Contention can be virtuous. It forces us to focus, but that focus is nearsighted. Managers ask their teams to work on high priority items, but priorities are often ad hoc (or post hoc!) Our releases have been driven by extremely smart people and they’ve been phenomenally successful, but the lack of a centralized, up-front plan and prioritization has lead to wasted effort and missed opportunities. It also bleeds those smart people dry, and we can do better.

The Future, In 4 Parts

We’re still going to use bugs to track work. We’re still going to need ideas from everywhere and we’re still going to need brilliant people, close to the code, letting us know what’s most important. What’s changing is that we’re going to bring some order to those ideas. It all starts with the feature page.

Part 1: The Feature Page

A feature page is a basic one-page summary of a piece of work. It’s written before implementation work begins, and brings all the information about a feature together, including:

• A summary of the feature’s motivation, goals and non-goals
• Bugs tracking work items
• Dependencies on other groups
• The feature team (Developer, UX, Security, QA, Project Management, &c) and overall owner
• Any UI designs, behaviour specs, test plans, and references necessary to make the implementation right, and usefully estimate its size

A feature page is more flexible than a bug for tracking these soft pieces. It introduces some maintenance cost for the feature owner, but the benefit is that every feature has a source of truth. Beyond the benefits this brings to engineering, it gives teams like QA, Security, Marketing, and Support a point source for the work they do for every feature we ship. Not having that source in the past has hurt us. Repeatedly, and significantly.

Part 2: Feature Tracking

When a new feature is picked up for work, the owner (not necessarily the main developer!) links to the feature from the tracking page. The tracking page transcludes each feature’s status line into an overall summary.

A given feature might move between releases on the tracking page as the realities of the feature’s size change; that’s fine. Having things on one page still lets us see at a glance what’s likely to make the next train, and the train after that. It helps us spot possible conflicts or danger spots earlier and lets people who care about different stages of the release focus their work. As this system starts to work, I can well imagine our development meetings re-orienting themselves to track this list.

Part 3: Feature Prioritization

Looking for a feature to work on? The product team is building a list with all of them. The feature list is, in a sense, the product team’s central deliverable: it maps our overall vision and priorities to a ranked list of feature work that embodies them. Start at the top of the list, work down until you find a good match for your skills and interests, poke the owner, and spin it up.

Part 4: Adding Features

The features on the list come from everywhere in Mozilla, as they always have. What’s new is that we collect them in one page; new features go into the inbox. Have an idea? Write up a feature page, add it to the inbox, and the product team will triage it into the right spot.

Of course, you can just do the work in a bug without any of this, but you do so at your own peril. Unlisted features have no priority, which means you’re back to contending for scarce resources. Writing the feature page is also an exercise in clarifying your thoughts, I don’t think the bar there is too high.

So to sum up…

I know, it’s a lot of words. And not every piece of work rises to the level of “Feature” and requires this overhead – straight up bug fixes rarely will, for instance. Nevertheless, I think the change is worth it. For me, ensuring we work on the right things, to say nothing of the benefits in terms of communication & coordination of work, are easily worth the cost. What do you think?