What do you do when there is a last minute request to exclude a feature from a release?

Question

There is a feature that has already passed acceptance testing, both internally and by the customer. It is a fully working feature. However, there is now a request to exclude this feature from an upcoming release. According to the customer, this feature should be removed because the users have not been trained on how to use it.

What is the best course of action to handle this situation? Should we design software in anticipation that a feature might be excluded last minute using configuration settings? Are there context-dependent solutions that might be more correct in some situations than others?

Answer 1

1. Remove documentation for the feature;
2. Disable interface for the feature (hide menu items or remove an option from a console command).

Everything else is way too dangerous.

Answer 2

My previous employer sells some software that enabled different features based on the particular license involved. So the ability to enable/disable features at runtime was a designed in feature. Generally, folks call this "feature driven development" (wikipedia article, decent book on the subject). It requires a lot of testing to find bugs that can be caused by turning features on and off. Since most folks in the office generate a license key for all features, the limited feature capabilities tend to be poorly exercised (and on more than one occasion, not tested at all until a customer called in to the help desk).

For your last-minute "fix" then the quickest solution will be to hide the menu/hotkey/button commands that turn on this feature. This will introduce other bugs. Be up front with your customers and project managers.

Answer 3

I would never write code such that features are switchable on or off -- unless that requirement was made up front.

Removing or disabling a feature is a change to the specification, and just like any other specification change, requires time to implement and verify. You need to ask why the feature is going to be excluded - is it still too buggy to be released? Does the client not want that feature at all? Is there some business reason to delay the feature?

Particularly in the case where the feature is perceived to be "too buggy" to be released, you need to be wary of whether it's that feature that is "buggy" or whether it's actually the release as a whole that's not ready for release yet and that particular feature is just the one where the problems show up the most - in which case, disabling that feature isn't going to help you very much...

Answer 4

We reply to last minute requests by discussing how important the change is to the customer. Making major changes just prior to roll-out invalidates the whole test-and-acceptance phase, so we either move the change request to a later release or move the roll-out date so that the last-minute change can be tested correctly (customers often chose to move the change to the next release when they learn that the alternative is to move the roll-out date :-))

Optional functionality is best (imho) switched on/off via configuration. Like you mention this must be designed from the start.

Answer 5

I've had to do this in the past, sometimes with features that have made it into production and turned out to be a disaster. I've done all of the following.

1) Config change to disable feature. Works where it's configurable 2) Disable/remove all UI entities which trigger the feature. 3) Disable the code in the feature so it does nothing (but appears to work) Had to do this where we didn't have access to the gui shell code.

As for whether you should design in the ability to switch features on or off, I'd look at the larger picture and look at how you add features currently. It's not a huge step to make features into modules which are at worst dynamically discovered. I like modular, so I tend to go this way.

Answer 6

Sometimes you can make a feature inaccessible as a short-term workaround, more easily that actually removing it. Check if it's acceptable to have visible artifacts (e.g. visible but disabled buttons and menu options).

You should make a feature easily switchable only if it's a requirement that users/admins be able to switch the feature on/off.

If it's easy enough that you don't mind doing it in anticipation, it's probably equally easy to do it when you know it's needed, and slightly easier to strip it back out.

If you can't disable the feature without significant risk of introducing new bugs, tell people that. Otherwise, you're basically volunteering to be the scapegoat when the inevitable problems occur, even though the real issue is whatever resulted in this last minute requirements change.

Answer 7

Based on your edits, I will guess this was a pretty integral feature. Removing it may have an impact on other parts of the system. Really, the customer shouldn't expect to be able to request fundamental changes to the system without incurring any costs. The costs in this case are for you to somehow disable this (maybe by just commenting out huge swathes of code) and then retesting to ensure that notthing was broken.

The simplest way to "disable" a feature like this would be to remove/comment-out the entry points at the highest level. For example: if the only entry point to the feature is a button on the UI, just comment out the line that creates the button. If there are multiple entry points, you may have to dig deeper to disable it.

Answer 8

Depends a whole lot on if it is dangerously buggy/broken/unwanted

If it cant do anything unsafe and they are just excluding it for ease of use reasons, lack of training docs or because it is broken we typically just remove the entry point to that feature from the UI and leave everything else in place.

If it is dangerously buggy we do that and add explicit exceptions in the core business logic so it cannot be executed.

The worst is where the feature is unwanted (regulatory change makes the concept illegal for example) and all references to the feature have to be removed entirely.

As you move down the list the potential for error increases. depending on your situation the first, or first two options may be something that can be don quickly, the third almost never is.

As for designing in the feature switches, unless the customer wants that I don't usually go that direction until the customer has demonstrated a history of making that kind of too-late choice.

Answer 9

My assumption is that management had sold this feature as a paid add-on, and that at the last minute the customer said they don't want to pay for the add-on (probably realizing it's not worth the money).

In view of that, management screwed up.

Answer 10

I have worked with a number of systems where feature access was driven by security settings. This makes this kind of feature disabling relatively trivial. Just don't enable the feature for any security groups. Unless the feature was enabled for all, testing with it disabled will have been done.

Other features which are able to be disabled easily are tied to code values. These generally handle a particular case of something such as a product, customer, or whatever. Disabling these features can be done by not enabling the related code value(s).

As others have noted, some features have specific UI entry points that can be removed. (The above cases can be special cases of this.). Removing the entry point(s) should enable you to ship the feature without enabling access. This is usually the least risky way to handle this case.

If features are developed on feature branches, you should be able to remove un-merge the feature branch and retest. This should be simpler than other methods of disabling the code. Creating a feature removal patch will simplify re-enabling the feature later. This is gives you a rough equivalent of a feature branch.