30
Nov 11

Know Thyself – NSID 2011

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.NSID 2010 Mosaic

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.


26
Aug 11

Rapidity

[This is a re-post of a post that originally appeared on the Future of Firefox blog]

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.


13
Aug 11

18 Months

A Girl and her Pine ConeYou became a little girl.

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.


18
Jul 11

Every Six Weeks

It’s astounding to me, but we’ve been living rapid release for a few months now. We’re moving faster. A new feature implemented today and landed on mozilla-central can be delivered to our users in 12 to 18 weeks, not months or years. Incredibly, the same process that gives us that agility is giving us greater robustness, too. Testing and stabilization of each release across progressively larger audiences helps us find and fix bugs early, and build confidence in the quality of each release.

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]


19
Apr 11

Deliberacy

a team in a rowboat on blue water
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.)

Continue reading →


14
Feb 11

Mike

Beltzner’s moving on.

When someone leaves the Mozilla Corp, it’s tradition for them to send a note to our global alias saying so. Mike sent his late last week, and this was my reply.

Continue reading →


13
Feb 11

1 Year Old

1 Year Old“Da.”

It’s assertive, when I come in the door after work. A statement of fact. “Da has arrived, Mother, in case you were wondering.” And then you squeal, and crawl down off the couch backwards like we taught you, and you crawl over to the gate by the front door and reach up for me to pick you up. And then you remind me where every light in the house is by pointing to them. “Teh.” (pointing) “Teh.”

6 months ago you couldn’t crawl, now you’re starting to walk. 6 months ago you couldn’t talk, now you’re babbling constantly and have 4 or 5 words that are consistent and recognizable, even if they aren’t quite English. 6 months ago you were a baby and now… you’re not.

A lot can happen in 6 months, and a lot has. A lot of firsts, too. Your first tooth, first flight, first foreign country, first beer. Yeah, that’s right, beer. Why? Because you won’t tolerate not having any. Every food that Mommy and Daddy eat, you want; and you’re fearless. Olives, pickles, pizza, steak. You are fearless, in everything, and it scares the crap out of me.

Parents think stupid things, Lily. You’re fascinated with light, will you be a photographer? You love books, will that last, will you read everything you can get your hands on, like Daddy does? You love food now, does that mean you’ll be a foodie, or that you’ll end up flipping a switch and getting really picky? We try to predict the future from the scraps of information we have, because you so constantly surprise and amaze us; we’re desperate for some ability to understand what the future will be like. It’s exciting and scary and foggy and incredible. I don’t want to rush things, but I can’t wait for you to start talking more, because I see the things going on in your head and I want to know all about them.

I asked Grandma when it stops. When each week stops feeling like there’s a brand new kid in the house. Grandma said, “it stops?”

When I write the next one of these, you’ll be 18 months old and, for all I know, you’ll be in college. Go easy on me, Lily. Gently. I love you more than anything in the world, little girl, but it’s all I can do just to keep up.

Love,

Daddy


02
Feb 11

Vacuums and You (or, Estimating Like an Astronaut)

I’m going to teach you a surprisingly effective trick for estimating better, but first I need to talk about dressing up vacuum cleaners.

Ze Frank is a pretty creative guy, but what makes him really interesting to me is his ability to make other people creative. It’s what he does. He catalyzes creativity, frequently among those who don’t consider themselves creative. And when he talks about how he does it, he talks about the value of constraint.

Asked to go and “be creative,” he notes, most people shut down. So, instead, he asks for something more specific. He asked them to make a whole earth sandwich; they made a few. He asked people to send in pictures of vacuum cleaners dressed as people. He got 215. Constraining people, forcing them to solve a smaller problem, made them better at it.

Creativity isn’t the only thing that benefits from constraint. Asking engineers (or, really, anyone) for “an estimate” is basically akin to asking them to “be creative.” They know what examples of the thing in question look like, they understand that it’s a reasonable request, they just don’t actually know how to get there from here, much less how to be accurate about it.

Back in the sixties, NASA and the US DoD were spending a great deal of money on engineering. They therefore took a keen interest in improving planning and estimation, not unlike the interest you might take if someone was setting all of your money on fire. Out of this interest sprung the mellifluously titled “PERT/COST SYSTEMS DESIGN” which, on the subject of estimation, made this central observation:

If you ask engineers for 3 estimates (Best Case, Most Likely, Worst Case) instead of 1, you get different answers.

That’s pretty exciting! Constraints get us different answers, and different answers mean more bits of information. If you’re not convinced that this is brilliant, though, here comes some next level awesome: A (weighted) average of these 3 estimates is a better predictor of actual completion time than any one of them. Specifically

(Best + 4*Most Likely + Worst) / 6

turns out to work pretty well in the general case. These so-called “PERT Estimates” or “3-point Estimates” give engineers credit for their assessment of “most likely” by weighting it heavily, but still allow optimism and pessimism to pull the average. I dare you to argue with this graph:

Likelihood of project completion date vs estimates (Science, bitches!)

Likelihood of project completion date vs estimates

Having 3 data points actually helps in other ways, too. It means you can more clearly quantify the uncertainty of a project by comparing best and worst case estimates, and watching to see if the distance between them shrinks over time. It means you can produce “optimistic” and “pessimistic” schedules. And, most importantly, it means that everyone is saying the same thing when they estimate.

Best, Worst, Most Likely. Try it for your next project, and see how it works. As we finish Firefox 4 and start looking at what comes next, there will be plenty of estimation happening, and I’m keen to see us bringing more science to the table. This may not be the right model for us, or we may discover that the coefficients need changing in our version of the equation; that’s fine. That would actually be a great result. My interest isn’t in pushing a particular tool, my interest is in getting better at planning, getting more awesome out to our users faster. I think we do that by looking for systems that have worked for others, and seeing how well they adapt to us.

And then we dress up the vacuum cleaners.