The combined mobile and graphics teams cut the beta blocker list for Fennec Native in half. The desktop team banged together a working prototype of sign in to the browser. The firefox tech leads worked with product and project management to nail down the kilimanjaro bug list for desktop. Madhava gave a great talk about the future of Firefox UX. I would have scored it as a strong success based on those outcomes alone.

And then this happened:

Hacking

• Scratchpad backending to github gists
• Jetpacks in scratchpad
• Task-specific icons in Windows 7 jumplists
• Finalized interactions and designs for the new downloads manager
• Sync meet-up and discussion to evaluate how to move forward with a smaller core, by moving data handling to components and allowing the Sync team to concentrate on the real Sync functionality
• Session Store meet-up and discussion on how to move forward with “Speedy Session Restore” as well as SS2 (rewriting SS).
• Initial explorations of a Fennec reading mode (post-1.0)
• Implemented Windows 8 appbar
• Roll your own one-off, bespoke debuggers in the scratchpad.
• Responsive Design tool for web developers

Lightning Talks

• Honza made Firebug’s HTTP Monitor a standalone component, and it can now remote-monitor fennec, too
• Gavin gave a great talk about code review
• Tim Abraldes demoed the Web App runtime
• Margaret walked us through Hacking Fennec
• Brian Bondy updated the status of our Windows 8 work
• Felipe found and fixed memory leaks with about:cc
• Dietrich walked through the state of the browser components team
• David Dahl went meta, and talked about giving Firefox talks in our community

I know I’ve missed things. I know some of it is still being written up. In fact, I’m not even the first to write a round up post. Here’s Finkle doing the same, and dcamp, and cwiiis.

FX-Team is big enough these days that it’s quite an undertaking to get us all together in one place. But man, it’s phenomenal when we do.

“I’m going to blindly refuse to listen to contrary opinions. I’ve already made up my mind, and will invent reasons why alternatives won’t work. Most importantly, I’m going to get this done my way, regardless of whether it’s actually the best decision, or even a good idea.”

You’ve never approached a problem that way. No one has.

But you’ve probably told yourself that story about someone else. You’ve been on the receiving end of one of these mindless and petty tyrants, in a bug or a mailing list or a standards body, and you’ve decided that you were seeing a rigid idiot in action. I know I have.

My philosophy of science prof used to talk about how the two important tests of a scientific model are whether it allows you to make accurate predictions, and how well it helps you discover new things. This matters more than its elegance or its intuitive appeal, though a really nice model has those, too.

The Rigid Idiot model does, for better or for worse, predict. It predicts more rigid idiocy, and people using that model to inform their interactions are likely to get precisely that. But it’s a pretty hollow model for generativity; it doesn’t help you make progress.

Here’s an alternate model:

Stress response pre-dates our neocortex, and outranks it. It is wired more deeply into us than language, much less rational discussion. And it has predictable effects. A person under stress (personal, professional, social, physical) will lose patience more quickly, anger easily, resist change, and consider fewer alternatives before making decisions. It’s an ancient, optimized cognitive path: less waffling when there are lions nearby. That it impairs our ability to function in this 10,000 year old thing called ‘civilization’ is evolutionary postscript.

You get to choose which model you bring to a conversation. When you assume that the person you’re dealing with is acting atypically, from point-in-time stress instead of born-in idiocy, you give yourself follow-up questions to ask about timelines, or conflicting pressures, or hidden assumptions. You give yourself ways to understand motivations, and implicit guidance about tone.

Not every asshole is a stress response waiting to be defused, but I swear to you that the single greatest improvement you can make to your success rate with these conversations is to switch models. I have seen people turn on a dime once their stressors are addressed. Suddenly there are lots of solutions, and confrontation turns to collaboration. It’s like a god damned secret decoder ring, to be honest.

With practice, you may even start to recognize the descent into idiocy in your own interactions, though it won’t make you immune. This is old, lizard-brain stuff. Like drunkenness, you can get better at detecting it, but you can’t think your way out of it. And, as with drink, my hope is that if you see someone a little worse for wear, you remember that it’s fleeting. Give them some time to sober up before assuming that’s who they really are.

Let’s go back to first principles for a minute. Releasing every 6 weeks is a cadence we set for ourselves to satisfy several constraints. Constraints like:

• Delivering security and stability fixes on a regular basis.
• Getting new features out to our users promptly, and being able to iterate on the feedback we receive.
• Containing the amount of code change and change-interaction that happens per release.
• Giving ourselves time to react to problems discovered before release (on Nightly, Aurora, or Beta)

Releasing daily wouldn’t work very well; it runs afoul of the last constraint. Releasing yearly would hurt us on the first 3. But the constraints are just about as well satisfied by 40 days or 44 days as they are by 42 days.

We derive great benefit from our current schedule. It satisfies these constraints much better than the old, monolithic release model did. But that is not to say that we should treat 42-day cycles as inviolate. We will adjust. We will add or drop days, or add or drop weeks when we need to. We’ll be respectful of the fact that other people build plans around our plans, and try not to alter schedules without notice, but at the end of the day we’ll do right by our users first and foremost.

Right now we’re not looking at moving the release to another day of the week (Tuesdays do have some nice properties), or adding a skip week somewhere to take us off-cycle for the next patch Tuesday, but those discussions are absolutely on the table when they make sense.

No religion here. 6 weeks is a nice spot in the constraint space, not a law. The first time we miss it, people will talk about us “slipping,” but the tail doesn’t wag the dog here. Firefox still ships when it’s ready.

Yes, Lily, I’m very happy. I’m always happy when I’m with you.

Dada kiss! hug!

Every time you kiss someone, you hug them, and then eskimo kiss. You kiss, hug, and eskimo kiss nana. You kiss, hug, and eskimo kiss mommy. You kiss, hug, and eskimo kiss teddy, and your tea cups, and my RC helicopter.

You smile a lot. You know that you’re supposed to smile for pictures, but you don’t really know how to make that happen on command, so smiling for pictures is sort of a grimace. I think it’s beautiful, but I suspect in a few years you’ll think it’s silly.

I watch you count toys and name the letters of the alphabet and I start to understand why parents all get this far off look in their eye when they talk about how quickly the time goes. I bet that part gets worse with time. The parents of 7-year olds in my life seem to feel it more deeply, and the parents of 15-year olds even moreso.

I wonder, as I have before, and even before that, which of your current fascinations will persist. You love bugs bunny cartoons. You can recite Sahara Hare verbatim. So can we. You put HP sauce on your scrambled eggs. You sit on the potty with an android tablet on your lap and watch nyan cat reaction videos and the duck song. Your childhood will be very, very different from mine.

At night, you can’t go to sleep without one verse each of Rainbow Connection, Climb Up Sunshine Mountain, and Twinkle Twinkle, Little Star. In the last month, you’ve started to sing along.

And then I tell you it’s time for sleep. And you say,

Okay. Goodnight daddy, I love you.

And it gets me. every. time.

I love you too, Lily. Happy birthday.

However, when we decided to rebuild Firefox for Android using Native UI, we recognized that the first release couldn’t ride the trains. The iterative release model that serves us so well with Firefox works best when most changes are incremental and independent. Building a new high-performance front end for Firefox on Android, by contrast, involves many interconnected pieces being rebuilt in tandem.

Right now, the engineering team is focused on building an amazing browser for Android phones, and we’ll have a beta to show you in the coming weeks. It might coincide with one of our regular 6 week trains, but it’s quite possible it won’t. If it doesn’t, don’t worry. It’s cool. Firefox for Android will get back on the trains once the native UI rebuild is finished, but for a change this major we have extra work we want to do before we send it out the door. We’ll only ship it once we’re happy with its quality and performance. If you can’t wait that long, check us out on tablets or try our early release Aurora builds. I think you’ll be pleased.

[This post originally appeared on the Future of Firefox blog]

The unexamined life is not worth living — Socrates

Socrates didn’t have a smartphone. If he had, he might have been less cavalier about the mortal consequence of an unexamined life. The distractions of life interrupt introspection, and we have built a world around us to collect and channel and amplify those distractions. We are no longer oaks putting down roots, we are leaves in a river; we float and bob in the current. It is beautiful, in its way, but it lacks depth.

Wake up and take control of your own cipher — Chuck D

The modern psyche aches for self-possession as much as Socrates ever did. We flock to the authentic. We eat local; we shop indie; we grasp for things with permanence and we try to hold on. Each new soothsayer peddling some ancient tradition as a restorative balm for the soul gets our enthusiastic, if divided, attention.

Self-knowledge doesn’t come from a farmer’s market or a flea market, though, and it doesn’t come in a brilliant flash of insight purchased from the self-help list at amazon. Self knowledge comes from looking in the mirror each morning and, from the moment you wake up, making your decisions in manual mode, not automatic.

Look in the mirror. Get past the human reflex to make eye contact with your reflection, and look at your face. Is it shaven? Groomed? Why? Because it’s what you did yesterday, and last week, and the week before that? Maybe it’s because you made a choice at some point to shave it. Is that choice still right? How do you know?

When I started NSID 5 years ago, I did it because I’d never seen my face with a beard. 1 month to see my own face in a new light. Have you seen yours? Have you seen it recently?

In the month of December, we support each other in this most basic piece of self-examination. We let it grow, let our faces express their base nature. We don’t shave. And we see what happens. Join us. Post your photos to the NSID flickr pool, tweet with the #nsid hashtag, track your colleagues in the aggregator. It’s good for your soul.

Socrates and Chuck D would want you to.

Last week we released a new version of Firefox. We shipped on time, 6 weeks after the last update, making it our first true rapid release milestone. There was cake. Now that we know that we’re capable of this velocity, I’d like to revisit the reasons why it’s important, and the lessons we’ve already learned.

Mission drives Mozilla. People sometimes forget that we’re a non-profit, that our only job is to make the Web a better place. Rapid release advances our mission in important ways. We get features and improvements to users faster. We get new APIs and standards out to web developers faster. We are delivering on the promise of the web at web speed.

Small, frequent releases improve quality, too. Engineers in the Mozilla community regularly say things now like “I don’t like not understanding this piece, let’s back it out and I’ll catch the next train.” We move deliberately. We don’t rush. And, even though it sounds like a contradiction, when we take our time we go faster.

There’s a great deal for us to be proud of, but we also need to be humble. This change was hard for us to make, and it’s been hard for some of our supporters, too. We have been glib or dismissive in the way we’ve communicated about parts of it. We live rapid release daily, and that makes it easier for us to see past the problems. We are also tenacious about the necessity of our new schedule, and tenacity can be mistaken for obstinacy.

We, everyone in the Mozilla community, all of us, need to communicate with clarity and sensitivity. We need to help the people who support our mission to understand why these changes are essential. We need to keep listening, and adjusting as we learn. We need to, and we will.

The push to ship faster isn’t some kind of software machismo. We push ourselves to ship faster because the web is under threat. Amazing and innovative people are doing amazing and innovative things and right now they have a choice: build for the web, or build for the walled gardens. The web can win that fight.

The open web is the most amazing, universal communication and distribution platform ever built. To win, the web needs to be agile and responsive. To help it, we need to be agile and responsive, too. That’s why rapid release matters.

I wasn’t consulted on this, and if I had been I’m not sure I would have approved. You’re a wonderful little girl. The best little girl. But 6 months ago you just were finishing up with being a baby, and I thought I’d have more time to prepare for the next thing.

Years from now, you’ll want to know all about this part of your life. There’s change everywhere, and you’re not so hot on forming long term memories just yet so you’re counting on your mom and me to take accurate notes. We’re trying. We have a running log that Mommy tries to keep up to date with every new thing you do:

Lily gives lots of kisses now, sometimes when asked, and sometimes spontaneously! She kisses her toys, pages in books, and definitely people.

Lily loves to share things with her toys – they often to get to share her water or her snack. She also likes when we wrap them up in a blanket and rock them to sleep.

Sometimes she likes the water, sometimes she’s really hesitant about it. Mostly she likes to play with the toys on the side of the pool. Life jackets? Forget it.

You literally learn new words daily. Some of my favourites in the last week: Hospital (sounds like hoh-pitatah), aluminum (a-lem-in-nen), tilapia (dala-pala), and dirt (dut).

Your mom and I talk about you a lot. What kind of school you should attend, what kind of activities you might be interested in, what we can do to ensure we both spend as much time with you as possible. We know we can’t predict the future. We know that you’ll have your own opinions, loudly stated. We know that change is constant, and that it can sneak up on you. We do it anyhow, because the illusion of a plan gives us something to hold on to when the uncertainty gets overwhelming. I think you won’t understand this the first time you read it but, when you have kids of your own, you might.

Today you ate a mouthful of sand at the playground.

Today you refused to eat your sandwich until you dipped each torn up little piece into a blob of ketchup.

Today you lay with me on the couch and made me put on music videos and then told me which ones to skip.

Today I have something in my eye.

You became a little girl.

I want to clarify an important part of the process, though, that I think many people haven’t yet understood. Remember, an individual release train is 6 weeks of development time followed by 12 weeks of stabilization:

New work doesn’t land on Aurora and Beta. Instead, those channels focus exclusively on working with our heroic and growing community of testers to spot any unexpected issues introduced during development, and then resolve them. Looking at this diagram, you might well conclude that we’d have a release ready every 18 weeks.

Aurora and Beta are so single-minded in their focus on stabilization and testing, though, that many engineers can move on to new work. If we take a step back and look at the broader picture, this is what actually happens:

During the 12 weeks that a release spends on Aurora and Beta, the Mozilla community is not sitting idle. They are already working on features and fixes for the next release, and the release after that. Every 6 weeks their work is picked up into the next Aurora, the next Beta, and the next release. When you look at this broader picture, you notice an important point:

There can be a new release of Firefox every 6 weeks, not every 12 or 18.

I’ll say it again, because it’s important: most of the time, we’ll release a new Firefox every 6 weeks.

Many people are surprised by this fact, though it’s been part of the process all along. When Firefox 4 came out, we committed to ship the next release of Firefox within 3 months. We did it, and when we did I think many people concluded that we have moved to a 3 month cycle. In truth, though, the only reason it took us 3 months was that our Aurora and Beta channels started off empty; they had to wait for the new release to make it through the process. The next Firefox is already in Beta, and is scheduled to come out 6 weeks after the last one. When that happens, yet another Firefox will enter Beta, and so on.

We’re studying the effects of the process carefully; it’s a big change and we will be flexible in our approach as new information comes in. We may decide that 6 weeks is the wrong interval, for instance, though it’s worth remembering that Firefox maintenance releases have been released on 6-8 week intervals for years, and sometimes included major changes. We’re also paying close attention to the impacts this cycle has on our ecosystem of add-ons, plugins, and other 3rd party software that interacts with Firefox. We’re working with large organizations, too, to understand how rapid release can fit into their software deployment systems.

Whatever adjustments we make, it’s clear that rapid release is a major improvement in our ability to respond to the needs of our users and the web. Every 6 weeks we have a new Firefox to evaluate and, unless some surprising and irreconcilable breakage is discovered, release to the world. No one will have to wait a year for the developer scratchpad now in Beta, or the massive memory and performance improvements already on Aurora, or the slick tab management animations soon to land on Nightly. Rapid release is already paying dividends, and we’re just getting started.

[This post originally appeared on the Channels blog]

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?