Talk:Freeze (software engineering)

Totally bogus?
1. Deferring UX after feature freeze as documented is totally bogus. User interface and experience work is part of the feature design process, not a "bug" to be fixed later on. Only bugs are fixed later on.

2. A feature freeze is pretty much coupled with a (semi-)official roadmap, as it implies to setup a list of features that will be contained in the upcoming release of a software, and the release date is effectively deferred to whatever-point-in-time the features are completed.

3. Compared to a code freeze (usually date-based), a feature freeze allows to setup clear metrics for what the state of the software must be in before a new release can be considered. As such, a feature freeze is either very specific in the features it lists, or alternatively, it is represented as a list of (rough) "user stories" (see Scrum (development)).

4. In complex software projects, a feature freeze may imply that missing functionality is determined only after the feature freeze during alpha/beta testing. In that case, the new software release is delayed until the missing functionality has been incorporated to make the product work as intended - or - a new feature may be removed prior to the new release, to target for it again in the second to next release.

sun (talk) 23:04, 6 August 2011 (UTC)