I don’t have many plugins available in the WordPress Plugin Repository anymore (and there are reasons for that), but I’ve been giving some thought to those plugins that I do have as well as the general level of code quality that goes into the first iteration of a plugin.
I mean, for some, plugins are merely small utilities that aim to do one thing and one thing well. Then, other plugins are much more advanced. I think these need a higher level of code quality to make them more maintainable.
But there’s one aspect of building plugins (or any software, really, but I’m specifically talking about WordPress plugins) that I find myself thinking about:
What level of plugin code quality of enough to ship the first version of a plugin?
Plugin Code Quality
Assume, for this post, that I’m talking about a single plugin that leans toward the smaller side.
- It does one thing,
- It does one thing well,
- It plays nicely with WordPress,
- It has relatively wide utility to users,
- It elicits a good amount of positive feedback,
- And it continues to work well as WordPress moves forward.
I mean, by all of the above points, the plugin has several levels of quality to it, right? But is it, say, enough to satisfy you – the author – as you continue to mature in your endeavors.
For example, let’s say that you’re becoming a better programmer and the plugin in question, though fulfilling all of the above, no longer conforms to the paradigm that you’d use to build it today.
Perhaps you’d do some different things differently:
- Maybe you’d do a better job of trying to follow coding standards when building it,
- Perhaps there’d be checks in your IDE or in your pre-commits that’d sniff your code,
- Would you break the plugin into more maintainable modules?
- If the plugin is procedural, are there benefits to refactoring it into an object-oriented paradigm?
And these are just a few of the questions I consider. I ask because I find myself in this situation. I mean, as we move through our careers we should be getting better at what we do, right?
But if a project is:
- available for free,
- satisfying customers,
- requires little maintenance,
- works well with the foundation on which it’s built,
- and it plays nicely with other plugins,
What’s the incentive to completely rewrite the plugin?
From a cost-to-benefit ratio, there’s not any. But for those looking to study the code and see what it is you’re doing, it may not be a solid way to release code. Or maybe it is. Or maybe it doesn’t matter.
- Do people study the code of plugins they download from the repository?
- Do we focus more on other developers or users?
The more I think about it, the more the conclusion at which I find myself arriving at is this:
- If a plugin is satisfying users and continuing to play well with others (and with WordPress), it doesn’t need to be refactored for it.
- It’s okay to assume that others may look at the code for the plugin, but perhaps it’s worth including a note that it’s not meant for academic purposes (outside the GPL) or provide resources or other work you’ve done that may be more updated.
- I think premium plugins should be held to a higher standard by virtue of the fact that these are tools for which people are paying. Thus, some of the money can be invested in tooling to provide the highest quality product possible.
- The above point is not to be confused with the idea that “free” should be of lower quality, but that they are done out of donated time and thus shouldn’t be held to the same standard.
Anyway, all of this comes from requests for an update to a plugin I once created and the thinking I’ve done around the single plugin and the plugin economy at large.
Perhaps I’m way off in my conclusion. And, if so, I’m happy to chat about it. It’s always fun and worthwhile to garner feedback from others on this kind of stuff.