LGND builds a lot of sites on WordPress, which gives us access to a vibrant ecosystem of more plugins than one could ever possibly need. If you need a specific feature (a calendar, event RSVP or custom fields, for example), chances are we already have a plugin that will slot in well enough to get the job done—and, importantly, help keep the price down.
In software, we’re often taught to avoid repeating ourselves and to take advantage of code reuse wherever possible—but sometimes the only thing to do is recode the wheel.
Five Things to Consider Before You Recode the Wheel
There are plenty of things to consider here—and unless you’ve got a truly generic problem (“car won’t roll”) that can be solved by a truly generic solution (“off-the-shelf tire”), it’s worth taking a moment to think about.
The first question is straightforward: do the off-the-shelf products meet the needs of the project? If the answer is no, it’s time to consider whether it will be easier to modify the existing plugin to meet those needs, or if it’s better to scrap it and start over.
With any existing ecosystem, plugins are going to vary widely in quality. For example, does the plugin you want to modify have any events or hooks you can use to modify its behavior? Is the code straightforward and digestible enough that you can simply hack on the pieces you need? Does the license support the work you want to do? Does the plugin maintainer play fast and loose with backward compatibility when they make updates?
If we’re talking about a large event RSVP system with payment processing and ticketing, and you need all those features but don’t have a massive budget, it’s probably time to go with a handy package someone else already prepared. That said, if you’ve got a simpler task to accomplish you might be in DIY territory. Ask yourself: how long it would take you to get an MVP up and running from scratch—and don’t forget to build in time for customization, testing, and bug fixes.
Lots of plugins are built without performance in mind, which is something that we value highly at LGND. If my options are to build a sleek, performant product that will help keep load times down (thus increasing customer retention and satisfaction) versus going with a heavy, bloated pre-made generic solution, and all the other items on this list check out, my choice is clear.
A generic plugin might come with a lot more features and code than you really need, and it might not be easy to disable. Do you really need a minivan here, or do you need a slick, performance sports car?
If you’re hooking into existing software with hooks or addons, or if you’re hacking your additions yourself, consider whether future updates by the plugin maintainer could break your solution?
Sure, you can disable plugin updates, but depending on the size of the plugin you might be opening yourself up to future security problems. Personally, when I finish a project I prefer to move on to new things. Sometimes this means finding a stable plugin I trust won’t break its API as long as I’m making a very light integration with it. Other times, this means I need to write something up securely from scratch.
Sure I could rebuild this entire plugin, but is my time better spent building cool features into the site in other ways? There could be other features that supercharge this experience that are not immediately clear at the onset of the project.
If you’ve got plugins that meet 90 percent of your needs but don’t quite cut it, don’t be afraid to at least consider writing your own solution. It doesn’t always make sense, but when it does you can often get a far faster, more robust product in place without a significant difference in time.
I often find that with the amount of time I spend learning the ins and outs of a plugin in order to modify it, I could’ve just as easily built something myself without a headache.
Plugins are usually built with the Least Common Denominator site in mind, but sometimes we don’t want to build the Least Common Denominator site—and that can mean reinventing the wheel just one more time.