Recap of week 1 at Mozilla

17 June, 2011 § 3 Comments

Today wraps up my first week working at Mozilla. I’ve had the opportunity to meet tons of people, take a couple sips from the information firehose, and dive in to some of the code.

Today I got my first two patches landed in the codebase. The first patch deals with a usability issue in the About dialog, and the other is a developer-related issue with respect to exception messages in the auto-complete feature.

Users will see these changes in Firefox 7, which should start to hit the Aurora channel around July 5th. When I talk to my friends outside-of-work, they are surprised to hear that we are hard at work on Firefox 7. This is especially the case since they have likely just installed Firefox 4.

About a few months ago, Mozilla committed to a new rapid-release cycle that pushes a new release of the browser out every six weeks. Each version of the browser is in development for six weeks and then in testing for twelve weeks.

Within testing, there are two stages: Aurora and Beta. The Aurora stage is updated to turn off features that weren’t complete by the time the release was cut and to fix any serious crashing or security bugs that are found. The Beta stage is only updated if there is a very serious bug found (we lean towards not changing a beta).

As a release moves through the testing stages, the number of users should grow by an order of magnitude. We hope to get around 1 million users on the Aurora channel, 10 million on the Beta channel (we currently have around 3 million), and continue our over 100+ million on the stable release channel.

If you want to see my changes sooner, you can download the nightly build of Firefox. You’ll also have the added benefit of seeing way cooler features than the bug fixes that I worked on 🙂

Proper Units for Task Estimation

19 May, 2009 § 1 Comment

Yesterday during a planning meeting, some fellow developers provided rough time estimates for some features that have been requested by the business team. The estimates looked like the following:

  • Create awesome feature X – 2 weeks
  • Resize GUI component Y – 3 days
  • Capture more meta information – 26 days
  • Support better use of internet tubes – 4 weeks

Much planning and thought goes in to numbers like these. There are often many smaller tasks that comprise one of the estimates given. But out of any of those estimates, did any strike you as out of the ordinary?

It turns out that while those estimates might be spot on, they either don’t leave much or create far too much room for error. According to the Pragmatic Programmer, there is a lot of weighting determined by these numbers. Estimates given in weeks are often budgeted to be off plus or minus a week or two. Estimates given in days are often budgeted to be off plus or minus a couple days.

Therefore, the two week estimate is a shorter time span than the 26 day estimate, yet is given much more cushion room. Estimating a large task can be very hard, as a task that may take 26 days or 4 weeks almost screams that there are plenty of unknowns.

Here is what the Pragmatic Programmer recommends:

Duration Quote estimate in
1—15 days days
3—8 weeks weeks
8—30 weeks months
30+ weeks think hard before giving an estimate

So what should have those estimates looked like?

  • Create awesome feature X – 14 days
  • Resize GUI component Y – 3 days
  • Capture more meta information – 4 weeks
  • Support better use of internet tubes – 4 weeks

Moral of the story: be wise when using units of time for estimation because product schedules depend on them.

Where Am I?

You are currently browsing entries tagged with sdlc at JAWS.