During my time as a WordPress developer, I have used hundreds of different plugins with varying degrees of success and ease. I have also written a fair number of Plugins to provide bespoke functionality to sites for clients. Whilst a number of these plugins (or theme modifications) have been carried out because of the lack of any available ‘off the shelf’ plugin, some have been written because the combination of available plugins that would meet the functionality needs for the site was just too complex.
What do I mean by complex, and why is it important?
You may have heard of the axiom that 80% of the users of a particular piece of computer software manage to use just 20 or 30% of the functions in the software package in question. The remaining software is obviously immensely useful to those users who DO use it, but for the majority of users, that extra code just may as well not be there.
So, why is this such a bad thing? After all, you’re getting that extra functionality thrown in for no extra fee, and, who knows when you might want to use some of it? Well, tempting though it may sound, I think there are a few reasons why you might want to reconsider all that overhead.
- The more code there is in a plugin, the more code there is to go wrong.
- The more code there is in a plugin, the higher the likelihood of code in the plugin interacting in unexpected ways with the code in other Plugins or Themes.
- The more code there is, the larger the ‘attack surface’ that can be exploited by malware.
- The larger and more complex a Plugin is, and the more it deliberately or accidentally interacts with other components of the WordPress site, the more difficult and time consuming it is to successfully and reliably maintain the code
- If the plugin provides a range of different functionality for the site, it can lock the site in to using that Plugin even if some of the functionality offered is not exactly what you want.
I decided to try and adopt the ‘Unix Philosophy’ of development with my Plugins. They would do one thing, and do it well.
What are the advantages of this approach?
- The code in the plugin is dedicated to that one task; it’s smaller and more manageable.
- The resultant plugin is atomic – if you don’t like how it does the job you can switch it out without losing any other functionality.
- The provision of documented and robust hooks for other developers because easier with smaller code-bases.
- By focusing on one task, the plugin can be written to deal with all aspects of that task without compromise.
- The small code base makes maintenance and testing easier.
- It’s easier for me to design and develop such Plugins than it is for me to consider architecting a multi-purpose monstrosity!
- Such single purpose plugins can be cheaper.
This isn’t to say that all in the garden is rosy; if you use a lot of ‘single purpose’ plugins then you can end up with an awful lot of menu entries in your Admin panel. I’ve attempted to deal with this by ensuring that all toolsforthinking Plugins that need a configuration menu nestle under a single toolsforthinking menu.
Sometimes Plugins need to be ‘big’ and you have to deal with the consequences of that. I don’t like to think about the number of hours spent applying tweaks to Woocommerce through the various (often poorly documented) action and filters available.
But other times, you just want something to do the job as quickly and as cleanly as possible without having to manage a behemoth of code. And that’s where toolsforthinking comes in.