Calendar:Development Strategies

This is a development strategy doc intended to attack two major problems in our development process:

• Too much time is spent blocked, waiting for input from reviewers/owners
• Patches are requiring too many revisions and partial rewrites, causing both frustration and wasted time

The biggest piece is that accepting the cost of communicating earlier and more often during the development process, avoids many false starts and rewrites.

Basic Bug/Feature Workflow

Lots of conflict can be avoided by careful ordering of work, and by ensuring that code and UI owners are all on the same page throughout the development process. Over the years, the workflow that we've seen that's most effective for driving bugs and features into the tree with the least amount of pain looks something like this:

1. Get UI buyoff (via the soon-to-be-defined UI design/review process)

Doing this before worrying about the implementation avoids large rewrites because of basic design differences.

2. Get basic code-level strategy agreement

Same benefit as 1. Even if you have a pretty good idea of how to attack a bug, the code owner may have big-picture information that would suggest a different strategy.

3. Code with ongoing discussion

When you're wondering about some implementation issue, or see red flags (like having to copy-and-paste chunks of code, adding weird dependencies, or violating abstractions), plunging ahead anyway is often the wrong thing to do. Instead, talk to a code owner or peer. Perhaps even post a patch fragment in the bug for input.

4. Review

Because everyone is better sync throughout, much of the feedback being requested requires less time on the part of the code owner than dealing with one big patch of the end of the process. In other words, even though there are more points at which blocking can happen, the total amount of time actually spent in a blocked state is often less.

Key success strategies

Pretty much everyone I've ever seen be productive and successful in the Mozilla development environment has done so by deeply embracing a couple of key strategies. I think the above guidelines only really work in combination with the following strategies:

• multiplex work on multiple bugs

  The key thing here is that whenever the existing bugs you're working on are waiting for feedback, go find another bug. There are various strategies that help make this managable, including:

  • pick another bug in a non-overlapping area of code
  • store in-progress work as a patch by using "cvs diff" with "patch -R"
  • use multiple objdirs
  • use multiple source trees
  • see also point 5 of the Development Strategies document.

• split work into manageable pieces

  This is critical, because difficulty to review often scales extremely non-linearly with patch size. Points 7, 8, and 12 of the Developing New Mozilla Features page address this in great detail.