Is there a downside of having too many features?

Question

I have worked on or seen different D7 projects in the past, with different strategies for features:

1. One feature per view, content type, etc, with a consistent naming pattern. The result is many features with small or medium size. This has been my personal preference in the past.

   Examples:

   • mysite_ft_vw_articles, for an "articles" view.
   • mysite_ft_ct_event, for an "event" content type.
   • mysite_ft_tx_categories, for a "categories" taxonomy vocabulary.

2. Multiple elements grouped into the same feature, e.g. if they are related to a specific section of the site, a specific topic etc.

I am now in a new project where we have to pick the strategy we want to follow, and some team members prefer to have bigger features with more elements in them.

To me the only problem I can imagine with having too many features would be performance. Some operations in Drupal may get slower if more modules are enabled.

The main problem with less but bigger features would be git merge conflicts, and side effects of "drush fu" on unrelated functionality.

Question

Am I missing something?

How big could the performance or memory impact be for e.g. 300 enabled feature modules?

What other downsides would it have?

Is there a recommended way / best practice?

Related

When using features to manage deployment, should I break my functionality into many little features or one big feature?

This question is asking whether to have multiple features or one big feature. But the accepted answer still suggests to group a lot of things into one (e.g. all content types, all views, etc).

I am asking whether to have multiple features, or even more features.

Note: the sites where I did this so far had fewer content types and views, so if there was a performance impact it would have been smaller. Also I have not compared few or many features on the same project to see which is faster. This is a new employer, new team, new project, I want to do things the way I used to on other projects, but want to evaluate the pros and cons and have a good argument, before I force this on a team that used to work differently in the past.

Answer 1

I'll jump in with an answer, though I agree with others that there is probably no single correct way.

My experience with features is that large features become very difficult to manage. Even one-feature-to-rule-all isn't a great answer, though it obviously reduces the conflicts possible, though that helps, because of the management of all those individual elements becomes hard.

In the past I have attempted to keep one "feature-module" for each aspect-feature of the site - so for example one feature describing a content type, and the views using it, and the rules, etc. Sometimes this is essentially one page, sometimes more. I have also tried larger groupings - bad idea - but not so far smaller ones (one for the actual CT, another for the view, etc.

The aspect of 'too many modules' is real, though I have dealt with perfectly functional sites with >200 (non-features) modules active. A mitigation you could use is for the live system to run with the features modules disabled, because their effect should be in the database and so the code is not needed. I haven't tried this, though.

From this experience I think that the choice should be to keep the scope of each feature small and very, very well defined. Most of the time I have got into trouble it has resulted from some aspect of a feature that is on the border between several elements -- it should probably have been its own thing not lumped into other things.

So: smaller features with very well defined scope for each.