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.

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-and-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 being requested requires less time on the part of 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 these are just guidelines that are subject to judgement calls, not hard and fast rules. 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, these guidelines are not a magic bullet: occasionally patches end up needing to be re-written, and sometimes bugs still bottleneck on 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:

• 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, but it also rewards the developer by allowing him or her to land code sooner. Points 7, 8, and 12 of the Developing New Mozilla Features page address this in great detail.