I mentioned the Unix philosophy ‘Do one thing and do it well’ in yesterdays post already, the User Switching plugin was a prime example of a WordPress plugin sticking to it.
In the past, I’ve discussed easy to use and expand plugins. Patrick Rauland posted about adding functionality to lean plugins yesterday as well. It clearly is a hot subject, but what exactly is this all about? Why should WordPress plugin developers care about keeping the number of features in our plugin as low as possible? I like to explain why this is important and a couple best practices to make this happen.
Do one thing and do it well
The ‘Do one thing and do it well’ phrase is actually a summary of the Unix philosophy. It might seem a bit far fetched to apply this to WordPress plugins, but I think it applies to pretty much all software development projects. Limiting the number of features in a piece of code helps reduce the following issues:
- Less feature bloat, only use what you need
- Easier to extend, including by third parties
- No vendor lock-in, as alternatives can be made
Let’s look a little bit deeper in why these changes are important.
Less feature/software bloat
Software bloat is a bad thing. It can impact performance, makes the code harder to test and increases the chance of bugs. If you can cut down a piece of code in your project, do it. If you can split your plugin into two smaller plugins, you should definitely look into doing this. Of course you can only do this for splitting functionality where it makes sense, like we are doing with taking out WooCommerce default integrations for example.
Easier to extend
When you design your code to have support for extra features, but you don’t want to include these in the core plugin, you’ll need an API to hook in the core plugin. WordPress has the Plugins API/Hooks for this purpose. When you allow extensions for your software to be made, you open your software to third parties as well. Everyone with access to your source code can start building extensions on top of your software.
No vendor lock-in
If you are unhappy with for example a payment gateway for an eCommerce WordPress plugin, you can switch to one made by another developer or make one yourself. When working with a piece of software that has a public API and is easy to extend, you are not limited to a specific vendor. As soon as the API is available, it can be used by third parties just as by the original developer.
Actually doing this is a lot more complicated
The theory is easy to explain. When putting things into practice, this can be a lot more complicated. We’ve been discussing taking out a lot more of the non-critical functions in the WooCommerce plugin. When one of us pitches an idea like this, we often feel it’s a good change. As soon as we dive a little bit deeper in the matter, it often turns out to be a lot more complicated.
Designing code to be easy to extend and use is complicated. You shouldn’t be afraid to refactor your code. The initial release is never going to be perfect, so you can always refactor changes like this. It will make your software a lot better in the long run if you invest in thinking things through.