Code Freeze when you are not done

Question

I am working on a project that has been working for a long period of time, and we are starting the final version of the product.

Ongoing testing efforts have found that there are about thirty defects left in the system, but we don’t have time to fix all these flaws (I’m sure this is a very common situation).

I had several discussions with different people about whether to freeze the code. Currently, my manager wants the code to freeze, however, to fix the remaining critical defects in the window between freezing and release (about 5 weeks). I worry that this is not the actual code freeze, but rather the “slush” code at best. Defects will be grouped by a team of senior engineers to make sure that only critical corrections from the remaining problems actually work, but from the initial view, critical problems appear to be about two-thirds of all missing defects.

I understand that having a code freeze provides certain psychological benefits for developers, such as providing a fixed end date for all work. However, this seems to be completely denied by my manager, who openly discusses the fixes that will go into the “after” freeze.

I was wondering if anyone has any other similar experience or can give me some tips on what is the best way to handle this situation. I'm starting to think that no one really freezes their code base the day they say they are going.

We plan to branch from the trunk in subversion in code freeze mode to make sure that the final version of the product is isolated from the development trunk, so I'm not too worried about the problems associated with changing the version of the product release.

Thanks,

Idos

EDIT: I believe the best way to explain the thinking of my managers is that this is not really freezing the code, but rather a “freezing functionality”, however, since all the functions have been in the product for some time, I think this is a gross simplification.

EDIT2: I would like to thank everyone for their excellent answers, unfortunately, I can only note one of them useful, although all 7 answers have been incredibly useful so far.

Answer 1

I think that actual code freezing is not possible. Typically, when code freezes, more intensive testing occurs. So what? Are all the issues that were found are documents for the next release? What if you find that the problem is so bad that the key function will not work?

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

From now on, you will need to deal with each error / problem as they become available. Each of them should be weighed in accordance with: what is the problem, what is the problem, how many days until the latest version for re-testing. Cost-benefit ratio for each problem. Only then can a reasonable solution be reached.

Answer 2

This is a balancing act.

On the one hand, it’s good to have a freeze period, but on the other hand, you are not interested in sending a product with critical problems large enough for your customers to leave.

If the problems are serious enough, no freezing code will stop me if they are my product.

Good luck

Answer 3

In this situation, I might think 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 4

Freezing code usually means that all known known errors will not be fixed. (And hopefully, of course, no new features are added). If errors are detected during freezing, they add new information, and depending on the type of sorting, the code may need to be temporarily “thawed” to fix the error. We hope that the changes made during freezing the code will be carefully considered.

It is estimated that every third error correction introduces a new error of an arbitrary severity. Code freezing gives you time to “convert” unknown errors (of varying severity) into known errors, with known severity.

A true “code freeze” where nothing could be changed would be pointless — what if you find a serious mistake? You could not just ignore him.

Answer 5

In our case, we fork when we start alpha (the main branch remains inactive for some time), and we freeze the code (no more than commits) immediately before sending the first client, when we decided that we made the correction of defects.

In the past, I worked for a company where code freezing did mean freezing functions (more functions added) and branching. Then we worked on the defects.

I would not name what you described, but this does not mean that you are creating a packing department in which you will hide the details and prepare the code for release.

Answer 6

AFAIK "Code Freeze" is actually, incompatible, meaning "Freeze New Code." The purpose of this is stability for debugging, bug fixes are not included in the freeze, because they are not new code, but are fixed in the old code.

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

Answer 7

Is your freeze really a code freeze or is it a freeze function? This is not 100% clear from your question.

Having said that, I agree with the above comments about branching and merging. This allows you and your developers to use the branch to fix bugs that you know about and those that will appear over the next few weeks. Then it allows you to integrate any critical error recorded back into the main (frozen) line in a controlled manner.

In this way, you can hope to eliminate the most serious problems without introducing too many new defects. Integration and regression testing are important here.