Managing obsolete modules
In every Drupal project, it is crucial for your application to be fully defined in code at every time and every state. When working with a configuration management based upon Git, Features, Drush based shell scripts and Master, it is possible to represent your whole Drupal 7 application's configuration state in a traceable and reproducible way.
Watch your Drupal modules
This way your team has a good tool to manage the development of the application and even manage the state of the Drupal modules in your application. Especially in large Drupal projects it is always important to know the modules you are dealing with, what modules to enable and to know what modules you can disable. Even already disabled Drupal modules influence your system and the overall development experience of your team.
For example, if you provide a large set of modules in your project, there will be a lot of noise for the developers when working on the sprint issues (e.g. a developer might find search results in the IDE for a code snippet in modules that are not meant to be enabled anymore). Therefore it is important all modules that should not be enabled are really disabled and uninstalled from the Drupal project. And, if possible, after that the modules should be removed from the file disk. As we are (hopefully) always dealing with a version control system like Git, we are safe to remove those modules without losing any information of the project's evolution.
Remove modules with Master
In projects that have grown for several months and no-one had a look at the modules directory, it will be very painful and time intense to remove those obsolete modules. To ease such tasks in the development workflow, we created the Master module some time ago. With the latest release of Master, we have also introduced a new command to assist you in finding the modules you really don't need anymore in your directory.
Drupal 7configuration managementmasterdrushdrupal planet english