DCRs and Breaking Changes
Have you ever been asked to change something when you felt you were done? It happens; customers provide feedback, security reviews reveal vulnerabilities in a design…there’s always a reason for a change. A “DCR” is a Design Change Request and are designed to track these types of change requests to the original design. Often DCRs will come in after features have been coded and when teams dive into their test passes and get lined up for release.
As we get closer to release (either Beta2 or RTM) we look more carefully at these DCRs to ensure that the reason we’re doing them is a good one and worth the risk to our deliverables and our dates. When I say “our,” I mean “our” in terms of a group, not just a single feature team. This is where the second topic comes in, “breaking changes.” Breaking changes are typically something that customers are concerned with when a new version of a product comes out; say the migration from v1.1 to Whidbey. However, within Microsoft, we have similar issues moving from build to build. Intra-cycle (Whidbey -> Whidbey) breaking changes are always a concern as teams react to the changes, but they are particularly risky during the push to a Beta or RTM, where the focus should be on solidifying the product (fixing bugs) and not reacting to unnecessary changes (e.g. an API or function behavior change.)
As part of our DCR process, we’ve included a check for intra-cycle breaking changes. Making certain that these changes are necessary helps us to deliver the right product, with the least risk to the project and with the maximum benefit to the team involved. Also, by performing reviews on these we’re able to track them better for our customers. Understanding what is changing between “drops” of the .NET Framework allows our partners to better anticipate and plan for any impact associated with moving to a new version and (hopefully/ultimately) allow them to focus more on delivering their feature and value, rather than deal with an integration that is more expensive that in needs to be.
Comments
- Anonymous
August 19, 2005
얼마전에 Microsoft의 Developer Division 대빵인 Somasegar가 Nulls not missing anymore라는 글로 Nullable Types의 DCR(Design... - Anonymous
August 19, 2005
얼마전에 Microsoft의 Developer Division 대빵인 Somasegar가 Nulls not missing anymore라는 글로 Nullable Types의 DCR(Design... - Anonymous
August 20, 2005
얼마전에 Microsoft의 Developer Division 대빵인 Somasegar가 Nulls not missing anymore라는 글로 Nullable Types의 DCR(Design... - Anonymous
August 21, 2005
얼마전에 Microsoft의 Developer Division 대빵인 Somasegar가 Nulls not missing anymore라는 글로 Nullable Types의 DCR(Design...