The benefits of a pluggable system are
- extensibility: the application can be dynamically extended to include new features.
- parallel development: since features can be implemented as separate components, they can be developed in parallel by different teams.
- clear development direction: since the plugin framework ideally provides a well-defined interface and documentation for plugin writers, developers have a clear roadmap for development.
- simplicity: a plugin typically has one function, and so developers have a single focus
But some of these strengths are also weaknesses:
- extensibility: does the plugin interface anticipate the ways plugin writers what to extend the app, or does it restrict extension. Designing extensibility to meet all use cases often takes several iterations, or extremely good requirements analysis.
- maintainability: the provider of the plugin framework not only has to make sure the plugin interface satisfies indented use cases, is clear and well documented, but also that it can evolve. Managing versions and backwards compatibility with existing plugins can be very hard. Hard enough that many practical implementations don't bother, and push the onus on plugin writers to update their plugins with each version.
- complexity: although each plugin works when tested alone, interactions between plugins can cause new problems, with bugs appearing only with certain combinations of plugins.
- testing: testing plugins can be difficult if the plugin system does not provide some form of mock plugin runner for testing, which is sometimes not possible, and testing is only available by running the plugin for real, which slows down development.
- artifical separation: a plugin typically has a single focus, but what constitues a single focus is set by the plugin api provider. If a plugin writer finds he needs a plugin that can reasonably do 2 things (as defined by the plugin api) in close tandem, he may end up having to implement two plugins and find ways of providing communication between them that is not presently provided by the api. He's then having to work around or against the plugin framework.
Designing a good plugin environment has many of the same challenges as designing a good library. If you are producing both the environment and the plugins yourself, then it's not so bad since you can update all the plugins as the environment evolves, but if the plugin api is open to all, then it requires careful planning and execution to get the design right to avoid too many plugin rewrites as the environment evolves.
"Second-system syndrome" described by Fred Brooks advocates that the second system developed is often excessively generic, aiming for ultimate flexibility, sometimes producing a "platform within a platform"/"inner platform effect". A pluggable design is often seen as a way out when requirements are non-existent or underspecified. To compensate, the software is made as flexible as possible to try to handle "whatever comes along".
Appologies if this paints a dreary picture - pluggable systems can be fantastic and offer a lot of strengths, but they come at a high price. Before diving into a pluggable system, it's prudent to draw up requirements for all the plugins that you will need to cover the functionality required. This will then help you decide if the pluggable design is worth the effort, or some simpler approach would serve equally well.