Code Freeze when you aren't going to be finished.

Question

Hi Guys,

I am working on a project that has been running for a long period of time and we're coming up on a final release of the product.

Current testing efforts have discovered there are about thirty defects left in the system, however we don't have time to fix all of these defects (a very common situation I am sure).

I have had several discussions with different people about whether the code freeze should go ahead. Currently my manager wants to keep the code freeze, however to fix remaining critical defects in the window between freeze and release (about 5 weeks). I am worried that this isn't an actual code freeze, but rather a code "slush" at best. The defects will be triaged by a team of senior engineers to make sure that only critical fixes out of the remaining issues are actually worked on, however from an initial look the critical issues seem to number about two thirds of the total outstanding defects.

I understand that having a code freeze presents certain psychological benefits for developers such as providing a fixed end date for all work. However this seems to be completely negated by my manager openly discussing fixes that will go in "after" the freeze.

I was wondering if anyone else has had a similar experience or could provide me with some advice about what the best way to deal with this situation is. I am starting to think that nobody actually freezes their codebase on the day they say they are going to.

We are planning on branching from the trunk in subversion on code-freeze-day to make sure that the final release version of the product is isolated from the development trunk, so I am not too worried about issues of changes being made affecting the release version of the product.

Thanks,

Aidos

EDIT: I suppose the best way to explain my managers' thinking is that it's not really a code freeze, more of a "functionality freeze", however as all of the functionality has been in the product for some time now I think this is a gross oversimplification.

EDIT2: I'd like to thank everyone for their great answers, unfortunately I can only mark one as helpful, even though all 7 answers so far have been incredibly helpful.

Answer 1

It's a balancing act.

On one hand it's nice to have a code freeze period, but on the other, it's in nobody's interest for you to ship a product with critical issues large enough to make your customers walk away.

If the issues are serious enough, no code freeze would stop me fixing them if it were my product.

Good luck!

Answer 2

In our case, we are branching when we start the alpha (the main branch remains dormant for a while) and we code freeze (no more commits) right before the first customer shipment when we decided that we are done fixing defects.

In the past, I have worked at a company where code freeze really meant feature freeze (no more features added) and branching. Then, we were working on defects.

I would not call what you describe a code freeze but more the creation of a packaging branch where you iron out the details and prepare your code for release.

Answer 3

AFAIK "Code Freeze" actually, uncynically, means "New Code Freeze". The purpose of this is stability for debugging, bug fixes not being included in the freeze because they aren't new code, but fixes to old code.

We prefer the term "down tools" for when you really really mean hands off the code.

Answer 4

The thing I could think of in this situation is to avoid problems,

If bug not fixed
   you will be in trouble;

if codefreeze === true
   fix your local version;
   update the dev version on SVN;

goto manager;
state the severity of the bugs;
follow her direction because she already got a plan;

Answer 5

Code freeze usually means all currently known bugs will not be fixed. (And hopefully it goes without saying, no new features are added). If bugs are found during freeze, they add new information, and depending on the view of triage, the code may need to be temporarily "unfrozen" to make a bug fix. Hopefully changes made during code freeze are very carefully reviewed.

It's estimated that one in three bug fixes introduces a new bug of random severity. Code freeze gives you time to "convert" unknown bugs (of variable severity) into known bugs, of known severity.

A true "code freeze" where nothing could be changed would be pointless - what if you found a major bug? You couldn't just ignore it.

Answer 6

I think an actual code freeze is impossible. Usually when a code freeze happens, more intensive testing happens. Then what? All the problems that are found are documents for the next release? What if you find a problem so bad that key feature will not work?

You have to have a way of dealing with each problem/bug as they come in. Since most good developers are lazy(opinion), branching\tagging and forcing the developer to merge or copy their changes to 2 places will stop most of them trying to make changes that are not 100% necessary.

From that point on, you need to deal will each bug/problem as they come in. They will each have to weighted according to: What the issue is, what the issue effects, how many days until final release to retest. Cost to benefit ratio for each and every problem. Only then can a sensible decision can be reached.

Answer 7

Is your freeze really a code freeze or is it a functionality freeze? It's not 100% clear from your question.

Having said that, I'd agree with the above comments about branching and merging. This allows you and your developers to use the branch to fix the bugs you know about and the the ones that will come in over the next few weeks. It then allows you to integrate any critical bug fixed back into the main (frozen) line in a controlled manner.

This way you can hopefully fix the most serious problems without introducing too many new defects. Integration and regression testing are important here.