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 re-writes, causing both frustration and wasted time

The biggest piece is that by accepting the cost of communicating earlier and more often during the development process, we can avoid lots of frustration and rewrites in the feature/patch endgame.

Basic Bug/Feature Workflow

Lots of conflict can be avoided by careful ordering of work. Note that these are all intended to be guidelines, not hard and fast rules. Obviously, 5 line changes don't require this much coordination, and changes without much UI effect don't require the UI piece. And issues encountered during coding sometimes effect design. Et cetera. These are all judgement calls.

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

The above workflow is intended to help people start on the same page and stay there throughout the development process. As a result, much of the feedback being requested is likely to be require significantly less time on the part of the code owner, so it should happen faster. In other words, even though there are more points at which blocking can happen, the hope is that the total amount of time actually spent in a blocked state will go down.

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 are only really going to help us if we do too. Specifically:

• 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 and give feedback 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.