Contact Us

Contact SLIM Enterprises today to get the most out of your business.

captcha

When Code Freeze Turns To Code Slush

November 21, 2017

Time To Market (TTM) is a vital concept that every executive understands. Releasing a product to market before your competition gives you a significant first-mover advantage. As such, project managers are extremely pressured to shorten their project schedules. But does accelerating code freeze optimize TTM?

All things being equal, the sooner you declare code freeze, the faster you’ll reach TTM. Slipping the code freeze date will most likely result in an overall schedule slip. But declaring the code as “frozen” when it actually feels more like “slush” will result in an even greater schedule delay.

Code freeze connotes no more changes to the software load. For those of us who are experienced software developers, we know that true code freeze rarely occurs. Bugs are generally found even after the load has been installed in the field. But at the very least, code freeze should signify that you’re not planning on churning any more code and that you honestly believe that the software can be released with some hope of stability.

When code freeze is declared, the project dynamics change considerably. The source repository is locked, processes are tightened to ensure no one introduces a change that could destabilize the load, and in some cases, development teams are dismantled. Since the code is locked, managers reason that developers are now free to work on other projects, and therefore reassign them to other teams.

What happens to a project that still requires development but where the project mangler artificially declares code freeze, thereby losing his/her development team? (Please tell me you already know this answer.)

As a project manager, you must keep honest. If the software load is not yet ready for code freeze, admit it. Sure, declaring code freeze on time might make you look like a hero today, but when people start raising bugs and you have to slip your project schedule because (a) the load is unstable and (b) you have no developers left to fix defects, the “slush” will hit the fan. And trust me, you’ll wish you would have been honest and pushed out your code freeze date.

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive

Categories

Recent News

Recent Comments