Becoming a Better Programmer

Chapter 22. The Curious Case of the Frozen Code

There she blows!—there she blows!

A hump like a snow-hill! It is Moby Dick!

Herman Melville, Moby Dick

Managers pronounce it in planning meetings. Developers utter it in reverent awe. Process ceremonies build up around it. And I have to stifle the gag reflex.

It’s a shout I imagine coming from a sailor in Moby Dick. Not “There she blows!” but “Code freeze!” It’s about as likely, and just as fictitious.

Our hunt for another mythical state of code.

Hunting the Code Freeze

Code freeze is a term bandied around with, presumably, good intentions. But often people don’t intend to say what the words actually imply.

A code freeze denotes the period between some “done” point—when no further work is expected to be performed—and the release date.

Exactly when are these points? And what happens in the middle?

The release date is pretty easy to define: sometimes called release to manufacture or RTM. It’s when the Gold Master of an installer disk is burnt and sent for duplication. In the enlightened twenty-first century we may not always ship physical media, but we tend to follow the mechanical conventions dictated by such a release schedule nonetheless. Is this useful and appropriate? Sometimes yes; sometimes no. It does lend a useful cadence to the delivery schedule.

But what is the preceding “done” point that initiates code freeze? Clearly, it should be the point when we consider the code to be complete, with all features implemented and ...