Partilhar via


Code Complete (CC)

What is Code Complete? Simply put, Code Complete is the point in which for the given milestone or checkpoint, that the features planned are completely coded. One might think that once a software application hits Code Complete (CC), that it is time to ship it out to the customers. Well, I'm sure that happens somewhere but not here does that happen. What happens once we hit CC is the next phase of the product cycle, testing to get to ZBB. Yes, there's testing done during the coding phase as all of the different features get coded to confirm that their functionally working but it isn't until after all of the features are coded, hence, Code Complete, that the Test Team can fully test the product.

Getting to CC on a large scale product like Microsoft Exchange, takes a lot of coordination and scheduling between the various teams and components. Due to its large scale, we have more than one milestone with a period of time specified when our developers primarily code the features for the new release.

Between Coding Start and Code Complete, the developers main focus is on the new features but they also fix bugs found along the way. The bugs come from the Test Team testing and through our eating dogfood. This bug fixing is needed to stabilize the code and to assist us in getting new builds into dogfood and to hit CC. Now as you may have already guessed, bug fixing can impact hitting CC. This is where having bug bars set properly help but above all, having high coding quality standards is even more important as this helps cut down the number of bugs found.

High coding quality standards includes having properly defined feature specifications, design documentation, test documentation, and Threat Models reviewed and completed prior to code start. It also includes using industry coding best practices with code reviews and testing called "smoke" testing, prior to checking the code into the main source code.

There are a number of ways to track the progress that developers make towards CC. We use what we call, Work Items, to track our developers progress. A work item is the lowest breakdown of a complete component. Work items can take from one day to a number of work days to complete the feature. Each work item is given an estimated time of check in date or Check-in ETA, which creates a rough schedule. Tracking the closing of the work items against the work item's Check-in ETA is a good way to see how well things are going against the product's schedule. Along the way, each work item's Check-in ETA should be adjusted to keep a more accurate picture of what is going on.

Once all the work items are completed, you are Code Complete. Hitting Code Complete is a terrific achievement for a team as there is a lot of extra work, stepping up and sacrifice made by all working on the product to get everything just right to make it happen.