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 

Doing this before worrying about the implementation avoids large rewrites because of basic design differences. The UI owners need to set the ui-review+ flag in Bugzilla to indicate that they have signed off on the UI for a given change or set of changes.

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 (or little-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/paste chunks of code, add weird dependencies, or violate 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 in better sync throughout, much of the feedback requested takes less time for the code owner than dealing with one big patch at 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.

Note that this is just a guideline that is subject to judgement calls, not a strictly defined process. Five-line patches generally don't need this level of coordination. Sometimes it makes sense to discuss UI design and code-level strategy together. A quick prototype may occasionally be useful. Implementation will sometimes turn up issues that effect the design. Furthermore, this guideline is not a magic bullet: occasionally patches end up needing to be re-written, and sometimes bugs still bottleneck for too long waiting for one person's time. But in general, they help a fair bit.

Key success strategies

Most people who are successful and productive in the Mozilla development world depend very heavily on a couple of key tactics in concert with the above workflow:

• 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 especially critical for reviewing, because difficulty to review often scales extremely non-linearly with patch size. However, it also rewards developers by allowing code to land sooner. Points 7, 8, and 12 of the Developing New Mozilla Features page address this in great detail.