Programmer Musings

BPGB: Frost-Bitten Features

In some environments where I've worked, new features were being added and bugs were being fixed up until the very moment that the code was released. This obviously leads to problems where one change generates new bugs that we have not yet had time to find, much less fix. Consequently, another buggy release goes out the door.

A Solution?

Some groups attack this problem with the idea of a Feature Freeze. Some period of time before the scheduled release (maybe two weeks), they declare a freeze on new features. From this point of time until the actual release, the only changes that can be made to the code are related to bugs found during testing. This is intended to serve as a clean-up period before the code is released. Also, there is at least some possibility that the actual features will be able to be documented before the release, because the documentation team may have had time to look at them before the actual release.

Once the feature freeze process becomes mandatory (which may be after one or more sort of freezes), there is normally one or two very painful releases where everyone follows the rules. In many cases there is a fair amount of wailing and gnashing of teeth as features that were promised don't make it into a release because they were not complete by the feature freeze date.

The Pain

At this point, the project person/team normally gets quite upset about promised features that didn't get done by the deadline. Maybe someone promised one of those features to an important customer, or there was just a feature that they were looking forward to having.

The developers also don't like being in the position of having agreed to something that they can not deliver.

Feature Slush

If pushed too hard to complete all of the features by a deadline, some developers may be tempted to finesse the definition of done a bit. Some will argue that their feature is done except for a little polishing or some minor bug fixes. In some cases, the programmer may actually believe that the feature is a few hours from complete.

In other cases, they may know there is a lot more work to be done. This can result in features that are complete (as in they have code in place that might work), but are not done (as in actually working as specified).

In one place that I worked this had reached an extreme where I saw some completed feature code that basically consisted of a couple of empty subroutines. The feature existed (according to the programmer). It just had a bug (it didn't work at all).

Not a Solution

One way to make this worse is to brow-beat the developers for not getting everything done before feature freeze. Another mistake is to push back the deadline, but add more to be done since we now have more time.

In at least one case I'm aware of, a pre-freeze deadline was instituted to give people time to finish before the actual feature freeze, but the problems that caused the initial problem weren't addressed. This just pushes the whole problem to a new level.

Controlling Feature Freeze

There are three things you can do to help make a feature freeze actually work.

1. A good definition of done is critical to defining when a feature is included. Everyone needs to be aware that done writing code is not the same as the feature is done.

2. The next part of a real feature freeze is realizing that not releasing features because of the deadline is part of the definition of a feature freeze. The iron triangle of project management still applies. If the deadline is fixed, the scope of development will need to vary.

3. A quick release cycle can reduce this problem. If they know there will be a new release in a few months, developers are less likely to fudge their code to get it in now. Likewise, a short release schedule means that the project manager is less likely to scream if a feature doesn't make this release. If the next release is a year or more away, a developer might be tempted to squeeze one more feature in, or a project manager might be tempted to convince a developer to finish something for the deadline.

Given a definition of done that everyone agrees to, the ability to modify the list of features that will be in a release, and a relatively short period between releases, it's possible to get feature freezes to work.

Conclusion

The idea of feature freeze is mostly aimed at getting a better handle on what will actually be in a given release. Without careful considerations for the implications of a freeze, it can make matters worse.