A Product Manager’s Ode to the Notion of “Code Complete”
Photo by Joshua Aragon on Unsplash
What is “Code Complete” and why is it important?
Code Complete (AKA Code Freeze) is a notion with which a lot of Product Managers are not familiar, making it a lost milestone in the release process. When Product Managers do not consider Code Complete dates as milestones in the release process, they increase the possibility of missing release dates, setting unrealistic expectations, and demotivating people in the company.
At its most fundamental level, Code Complete is when your development team completes all of their work in a sprint and is ready to hand it over to the QA Engineer for testing.
For those who are not too involved in the Quality Assurance function (more on that later), the QA Engineer needs their testing environment to be completely frozen so the integrity of the platform will not be compromised by new modifications while they are testing. If we didn’t have Code Complete, we would be like that famous shampoo prank where dev is the man continuously squirting new shampoo on QA’s head: you can’t introduce new code to an environment that QA is in the middle of testing. For the sake of the product not being riddled with bugs, we need the notion of Code Complete.
What does this have to do with Product Managers?
Since Code Complete is highly valued and respected by multiple key players on your team, you can use it to your advantage when setting dates and expectations. As a PM, there is great risk in setting concrete commit dates (or even target dates, for that matter). There are a lot of variables to consider when setting these dates, but you can limit the amount of noise and stress by focusing your attention on when dev hits Code Complete.
Setting a Code Complete date internally allows for development to complete their work by a certain date which supports a smooth transition into QA. Without the notion of Code Complete, it becomes extremely difficult to manage the hand-off between development and QA because devs may be finishing their projects at different times. Also, it creates an environment for scope creep to flourish due to its lack of structure. Having a separate milestone where development submits their code for testing creates a checkpoint of accountability and feeling of achievement.
After you have the Code Complete date, you can work with your QA Engineer on the anticipated time needed to test the system, fix any critical bugs, and correct any other unforeseen issues within the QA cycle. From that information, you can establish an aggressive target release date and a reasonable commit date, two other important milestones in the release process (the target release date being the soonest you will have a product ready and the commit date being the absolute latest a product will ship). This gives your team the ability to hit their dates at the very least or, at the most, over perform and over deliver!
TL;DR
Including the notion of Code Complete as a milestone within your release process prohibits the release from spiraling out of your control and allows you to manage expectations across your company.
