Has business overplayed plugin mentality?
Updated Jul 20, 2022; Originally posted Oct 14, 2020
There has been an interesting evolution of plugins over the past 10 years, growing ecosystems around content management systems, cloud applications, and eCommerce platforms to say the least. This has extended our abilities as businesses to tap into additional capabilities we would not have as easily otherwise.
With the maturing of app stores, people have grown very comfortable with simply visiting a "store", clicking to install something, and having it "just" get installed automatically by a slightly miraculous process in the background ready to start working in mere minutes.
It's brilliant. It's scalable, can benefit thousands or tens of thousands of business users with very little infrastructure or additional effort on the part of the developer or end-user other than providing the plugin functionality that businesses need. It's everything the internet is supposed to allow for in its global instantaneous collaboration.
When it works, that is.
Indeed there are a good many plugins (we'll lump in the "modules" and "addons" as similarly motivated and positioned) that are very well built and supported and do exactly what their users need; not more and not less.
But what happens when plugins aren't suited for us? Have both plugin makers and businesses over-played the just-add-water feeling that simply by installing this plugin, all my issues and benefits from here on in will just work?
Assume nothing
A plugin may do what it says perfectly well. All the same, does it suit all aspects of your workflow fully? Countless times we have been faced with a business confused by why part of its plugin workflow and functionality doesn't do what they either need it to do or thought it offered out of the box.
Give your plugin investigation a chance to evaluate all parts of what you need it to do. Assume nothing!
It means you're on top of your business and not trusting important functionality to a piece of software you have little control over
Developer credibility
There are good developers. There are excellent engineers. And ... there are dilettantes. Do your due diligence on the developer background of a plugin you're considering using. Do they have a history? Do they have more than one plugin they have created? Is this a company supporting the development of this plugin or one person?
And reviews, while reviews aren't everything, they do give you a sense of the depth of time, revisions, changes, and iterations on how this plugin has served people. Don't sweat it too much if there are one or two bad reviews, it's entirely believable that someone somewhere will find a problem – finding 100% glowing reviews may be equally suspicious.
Workflow and Decision Intelligence Functionality
There is a time and a place ... is the planned role of a plugin aligned with the workflow and decision intelligence automation requirements of your business?
tl;dr -- the more narrow the requirements and focus of the plugin, the more likely you understand its role in your workflow.
For example, a payment gateway plugin for "Merchant Gateway Company" would (you would expect) handle managing credit card transactions for customers paying you. Nice and focused; should be easy.
Feature checklist starts with refunds; does your company process refunds? It's an ECommerce company, so sometimes it does come up. Your staff have a refund functionality in your commerce software so they click it and it pushes the instructions back to the gateway plugin. This plugin does refunds? Right? (right?). If it doesn't, then your staff will have to do them manually, how much more work is that?
Next up is data storage and security model; this is privacy sensitive data so is this going to work within your policy and liability expectations? Banks almost universally expect PCI compliance now (this is workable if truly needed at the system config stack level); do you also want to take on liability when secure data -- even encrypted -- lives in your systems? Modern gateway systems and integrations use tokenized relationships to keep secure data in the merchant gateway world instead of yours. Does your plugin support this?
There is a myriad of workflow and decision intelligence points to confirm as you consider using a plugin. That's not a bad thing, it means you're on top of your business and not trusting important functionality to a piece of software you have little control over. But it's not optional.
Versions
A good, but not necessarily perfect, benchmark is where this plugin is at in its life cycle.
Has it hit version 1.0+? If so there's an expectation that it's been through growing development cycles, the alpha phase, beta release and now into its "real" life as a bona fide plugin having been vetted, tested, and finally released under the pretense of "real-world ready".
If it hasn't yet hit version 1.0+ and it down near version 0.1 or 0.2 then there's a good bet there is a lot of growing, changing, tweaking, and with that, risk of things not quite working the way you might think they should – in other words, expose your business as little as possible to this and treat with caution. Doesn't mean it's bad, just very young, and not tested heavily.
Has it hit version 2.0+? If so there is a good chance that this has gone through several development cycles – good – iterations, bug fixes, client feedback, a crisis or two, and more improvements. Often software at this stage may have been entirely rewritten as well, usually after the developer made all their mistakes in version 1, and then figured out how to do it properly. This benefits you a good deal knowing this as part of your risk exposure should you opt to work with this software.
A general guideline (this assumes that developers use a standardized versioning specification, but some uses differ):
(note: this is a very high-level guideline, for details on versioning best practices in software development read here)
alpha or beta : For testing, engineering evaluation, and strong intestinal fortitude only.
0.1 to 0.9+ : Early days. Treat with caution. May not be suitable to rely on heavily. Limit your business exposure especially if you're not technical or don't have technical/engineering support readily available. Treat as a work in progress.
1.0+ : Credible starting place. While version 1 doesn't mean by any stretch that things are perfect, you could look more seriously at how this may slot into your workflow in the real world. Still, caution is warranted, as this may be a young piece of software.
2.0+ : Maturing, worth serious evaluation. Generally, version 2 and up have established themselves as credible, that they do what they say they will do, and have a track record of updates and improvements.
3.0 and up : With a (hopefully) strong lifecycle in place these should be good contenders to look more seriously at. Make sure, however, that you still check references, last updated timeframes, and reviews. Make sure that the developer has not added a pile of new functionality that may not really be at the same maturity as the core plugin. Adding new features is great; but adding buggy new features could be a perilous, hidden problem waiting to happen.
There are good developers. There are excellent engineers. And ... there are dilettantes.
Beware the Upgrade Button
It's a pretty bad feeling having a mission critical business system be taken down by an upgrade gone wrong. Adopted from the desktop, plugin developers and other online software platforms alike have adopted the idea of the click-it-and-upgrade-it button culture.
Unless you are truly running the most default, base-level version of your plugin and platform (very few people really do) you should be wary of clicking the upgrade button. When it goes wrong, it can go very wrong and take your business down – sometimes for quite awhile while developers and support teams sort out what happened.
Software, especially plugins, generally depend on other software with which it must co-exist. If one version is at one level, it may not support another piece of software that's working at a higher level. Upgrade "against" these dependencies and you risk taking the whole site or applications down simply because one plugin can no longer cope or interact properly.
It may seem old fashioned, but choosing to upgrade the conventional upload-files-manually-and-test method gives you the most control over percisely what is going where, reading the upgrade documentation on what is happening, what is changing, and what to look out for. It also puts your team involved on a standard Quality Assurance lookout for potential issues.
The more early-release (read: less mature) – see versions section – plugins you're using, the more wary you should be about the "Upgrade Button".
Developer Staying Power
"What have you done for me lately?", that's the usual refrain. In this case, it's "what have you done to get here?".
You want to know that the developer or software team/company has been active in this space. Evaluate what else they seem to work on, that their story on getting to this plugin is inline with their history. If they've been writing nothing but audio encoding tools for ten years and then all of a sudden release a content management system seemingly out of the blue, it's akin to a florist opening up an accounting firm. It could be great, and they could be brilliant, but it makes you wonder about the back story of how they got there. Remember, you're entrusting a part of your business to this, you owe it to your business to understand.
In short, you want to know that by choosing their plugin, that there is a reasonable expectation that they understand the space because they've been there for some time, and that they are likely to be there, supporting this plugin for years to come.
Go it Alone
You may find yourself faced with the possibility that your plugin options are either too limited, not fully featured enough, or not evolved enough for your to entrust to your business full time. It is possible that the market or complexities involved in your plugin concept haven't yet justified such development.
You may decide that creating this yourself is a route to consider.
- you can control the feature set exactly as you choose
- you can craft a workflow that suits your team
- you decide the fields/data required and any validation for data entry
- you can dictate integrations that you need
As with any investment, the value proposition will come to light as you assess potential scope, investment required up front ammortized against your projections for capital recoup of funds against new savings and earnings from your new plugin.
