Insomnygen

Plugins are great. They are a huge timesaver and they save you from having to re-invent the wheel when you need to re-implement an often used feature for a project. But they have a pretty dark side too–and to be fair–it’s really not the fault of the plugin, it’s actually the business expectations surrounding their use that is to be blamed.

When a CEO or project owner is sold on a specific feature, utilizing a specific plugin, configured a specific way, you can’t really blame them for setting an expectation. Building prototypes with plugins are dangerous for this very reason, and the people who sell their ideas with plugins are even more dangerous.

The second a plugin doesn’t work “the way we want it to”, it’s up to the developer to modify it and mold it to match the spec. But what happens if the plugin simply cannot be retrofitted without major modifications? If you have to fork the plugin to hack its innards to meet your project deadline, I say that’s going too far. Now you have to maintain the forked version of the plugin, and who wants to be stuck with that? I certainly do not, at least not in my day job, where I have plenty of other things to worry about already.

I say let the developer choose the plugins. Don’t let the project managers or salesmen pitch their ideas hinging on a particular plugin. We’re building features, not piecing together pieces of a pre-built puzzle. And when a plugin is used, understand its limitations and work within them.