Thursday June 02, 2005
What kind of ARC review do projects need? Alan Coopersmith writes about making a simple change to Solaris that has a simple architectural impact. This raises the question of how are changes classified?
Obviously, we want to be proactive and intentional about making changes to our products, since the alternative of being suprised by unexpected changes usually means upset customers and broken products.
The development processes we use tries to formalize this intent by asking two basic questions about every proposed change:
- Do we want this particular change?
- Is this the best way to make the change?
The former is primarily a business decision, and the latter, a technical one.
Many times, the want question is obvious - Priority 1 bugs are more "wanted" than Priority 5 ones, competitive pressures may demand certain new features, etc. I won't spend much time discussing this topic, as I want to focus on the technical path.
Architectural Review Committees (ARCs) are made up of senior engineers and other domain experts, and are responsible for the technical review and approval of these changes. The first step in that review process is to determine what kind of review a particular proposal requires:
- The simplest review is None.
- Projects that
- have had an earlier proposal approved by an ARC,
- do not introduce new interfaces visible outside their own project, and
- do not alter any interface visible outside their own project
Most bugfixes qualify for this level of review.
The documentation provided in the bug report (evaluation, suggested fix...) combined with the usual peer review is deemed to provide sufficient technical oversight.
- Next up is Fast-Track
- A lightweight
process for simple cases whose architectural impact
is obvious, and that are not likely to be controversial.
Projects suitable for a fast-track review generally apply "common practice" in a frequently-performed change or addition.
The fast-track process is primarily handled as email discussions and can take as little as a week's time to complete.
The intent is that 80% or more of the changes being made will be either self reviewed or fast tracked
- If you don't qualify for any of the above shortcuts, you need a Full ARC Review
The full ARC review process involves a combination of email, detailed project specifications, and formal meetings. The time required varies considerably, but teams should schedule reviews early - an inception review by mid-prototype stage, with commitment reviews between alpha and beta in order to allow time to incorporate any ARC required changes before integration.
Technorati Tag: OpenSolaris
Technorati Tag: Solaris
( Jun 02 2005, 04:10:57 PM PDT )
Permalink
Comments [0]
This is a personal weblog, I do not speak for my employer.
