Call me strange, but I really enjoy client-centric plugin development. I think plugins are a powerful extension model for large software products, especial those of the pre-packaged, commercial-off-the-shelf variety such as MS Office. In a geek sense, plugins are awesome.  However, over the years, I’ve grown skeptical of projects where the assumed solution is a plugin, or extension or add-on if you prefer.

Plugins can be great, but they’re not right for every situation. I start the product design phase by assuming that a plugin is probably not the right option for the project and plan to implement a plugin only after I’m satisfied it’s the best, and often only, solution for the problem the project is aiming to solve.

Let’s Agree on What We’re Talking About

Before examining what I feel are the pros and cons of plugins, let’s have a brief discussion on terminology. I find the nuances between the categories of plugin, extension, and add-on tend to be highly technology/platform specific while the functional difference between them is more or less insignificant. So I’m choosing to use the term plugin generally to refer to:

a packaged software component that conforms to the public API of a host program, is intended to augment the functionality of the host program, and appears to the end user to be a seamlessly-integrated part of the host program

Additionally, I want to acknowledge that plugin architectures exist for server-side products, and that those solutions share many of the attributes of their client cousins. If anything, server-side plugin development has significantly greater productivity gains because you can eliminate the end-user “technical familiarity” limitations associated with leveraging them. However, this article takes a client-focused perspective.

The Value of Plugins

With that out of the way, let’s continue with what makes plugins great and when you should use them. In my mind, the primary benefits of plugins boil down to these two things:

• user familiarity with a product
• integration into a larger functional process flow

User Familiarity with a Product

Building an intuitive application that is easy for anyone to use is hard. Very hard. Whole disciplines have emerged over the last few years where practitioners devote themselves solely to the study and understanding of design-focused topics like user experience and practical implementation techniques such as user-centered design. If you believe your passion as a developer and the raw, untapped value of your application are enough to get people to use it, you’re probably wrong.

Because building an inherently “usable” system is difficult to do, simply encouraging people to engage with your new application can be a challenge. If there is a business-oriented expectation that a new user will need to learn how to use a new product, that product better deliver tremendous value that the user can’t get elsewhere, otherwise that user simply won’t bother investing the time to become fluent with your product.

Plugins can help overcome some of the challenges associated with user adoption by exposing the new functionality as part of an application the user is already familiar with. If a user already knows how to use Outlook and already opens it first thing in the morning, you can gain a tremendous leg up in encouraging user adoption by making your application a part of Outlook.

Integration into a Larger Functional Process Flow

What I mean by integration into a larger functional process flow is that not every feature or function deserves its own application. Some features, even powerful and valuable ones, only make sense in the context of broader functionality.

If your project is intended to provide a mechanism for generating rich graphs and charts from data stored in your CRM system, it doesn’t really make sense to write an entire word processor just to satisfy the “must be easy and intuitive to embed into text documents” requirement. A plugin for Word will likely be a better option for such a requirement.

A more nuanced but less clear-cut example of when this guideline is applicable would be this: if you are developing a programming language, should you write your own IDE or adopt Eclipse with your language supported as a plugin as your development environment?  It’s a complicated question with many non-technical influencing factors.

In practice, I’ve found that evaluating projects on this scale tends to feel less like the glaringly obvious first example and closer to the more nuanced second, where there are likely compelling reasons from the business and product strategy points-of-view to invest in re-implementing functionality that may offset the technical benefit of piggy-backing off of an existing application.  Even when a plugin may be the right technical fit, it may not make sense from a business perspective.

But even in those less-obvious scenarios, engaging in the exercise of thinking through how a new feature could be incorporated into a tool the user already has and loves is a valuable exercise. Intelligently leveraging the work of others is a practical reality in professional software development, so you should at least talk through the possibilities plugin architectures present.

Next week, we’ll look at the reasons why you may want to avoid a plugin architecture and implementation.