Using WordPress as a Golden Hammer

This topic started as a comment thread on Google Reader, on a post about a web application being built on top of WordPress as a “platform”.

I don’t want to call out the specific project or post in question, because the point of this post is to educate, not to slam or put down any particular person or application. It’s sufficient to say that the core of the application was unrelated to blogging or content management (which is what WordPress can be a good base for, BTW).

Ground work

Even if you haven’t heard of the Golden Hammer anti-pattern before, it’s very likely you’ve heard some variation of the quick summary of what it means: “if all you have is a hammer, everything looks like a nail“.

This is unfortunately a common pitfall in the software development world. It has many variations, but one of the most common comes in the form of a developer being overly familiar with a certain tool or system (often to the neglect or even exclusion of any others). Since the developer is so familiar with the particular thing in question, he begins to see all other future possibilities in the context of that thing he is most familiar with, and it will lead him to choose it for tasks where it may not be the most appropriate.

Like I said, this one is very common – common enough for it to earn its place as one of the most well known software development anti-patterns. This means that it is widely recognized and regarded as a bad practice by most people who know what they’re talking about in a particular field.

To WP or not to WP?

In light of that, only one question remains: is creating an application that is not primarily (or even peripherally) related to content management or blogging by building it on top of a blog/CMS product/platform a case of this anti-pattern, or not?

I would argue that it is.

Exhibit A: WordPress Itself

If you’ve been around the core WP dev scene for long enough, you will have seen innumerable requests or proposals that this or that feature be added to the WP core. What is the usual, default answer, unless an excellent case can be made for why it fits? That’s right: “no”, or sometimes more politely, “do it in a plugin”.

There is a very good reason for that policy, and it’s basically a recognition of the principles that my argument here is based on. The idea is that anything that is added to the WP core increases the overall complexity of the system, and that is a very expensive proposition when you want maintainable code in the future. It increases the burden of maintenance as well as diluting the focus of the development effort.

Since maintainable code is essential for being able to quickly fix bugs, add new features, improve performance, and virtually every other change you will inevitably want/need to make to successful software, its importance cannot be overstated. For this reason, Matt and the other core devs will quickly turn down any feature proposal that is not essential to the core purpose of WordPress as a blog / CMS system, and they are very right to do so.

Do Likewise

You should take the same approach with your software. You should vigorously oppose the inclusion of peripheral code that is unrelated to the core function of your system. Basing your application on an entire codebase that is largely unrelated to your application’s core purpose is essentially the exact opposite of this approach.

“Platforms” vs. …

One of the biggest things (IMHO) that drives people towards building things on top of WordPress is that it’s talked about and considered to be a “platform”. There is certainly truth to this; WordPress can be a pretty good platform for building a CMS-style application on, since that’s what it’s meant to be.

Of course, the problem arises when people confuse “platform” to mean something you can build anything on / with. That usually isn’t the case, and it certainly isn’t for WordPress in the case of applications that are not primarily CMS or blog focused.

The issue is that the developers of WordPress regularly make important decisions regarding the structure of their code. They make these decisions with the driving goal of what will make it the best blog / CMS product / platform, and any other considerations are justifiably ranked extremely low or ideally discarded.

This is a huge issue if you’re trying to build an application (not a blog or CMS) on top of WordPress, because you will find yourself constrained by those decisions, when they often will not (because they should not) be made to facilitate you doing something unrelated with the codebase. You will find yourself working around parts of the system that are rightly designed for their intended purpose, when you are trying to use them for something else.

You will find yourself being required to update your code in response to updates / changes made in the base platform that are unrelated to your core functionality or to patch security issues that your product should never have had, but it has inherited them. You will have to look at every potential new feature or change you make through the filtered view of “what’s the best way to do this within WordPress” as opposed to “what’s the best way to do this”.

… “Frameworks”

Don’t get me wrong, constraints can be a good thing. They are great when they are at the appropriate level of abstraction. This is where frameworks come in. Things like Ruby on Rails (or the PHP clones like Cake) will impose opinions / constraints on how you write your applications as well, to varying degrees.

The difference is that frameworks like those are designed to have general purpose applications built on top of them. They will often handle the “plumbing” details like data access, etc. so that you can focus on writing the actual application code necessary for your application without being burdened by unrelated concerns. Platforms like WordPress, on the other hand, are existing applications that are built to be extensible within the scope of what they’re designed to be.

Can you, by looking hard enough through the WP goggles, find a way to map the unrelated features of your application to what WordPress provides, and only write new stuff or workarounds when you really, really can’t squeeze and make it fit? Sure, with the right hammer you can bang those square pegs into round holes all day long. The problem is that at the end of the day, the square pegs get pretty thrashed.

Wide Is The Road That Leads…

… well, you know where. The fact is that PHP is a very easy language to learn quickly, and modifying WordPress (via themes or plugins) has become a popular first step into web development. There’s nothing wrong with that, but there is a dangerous side to it.

Just because something is easy and/or quick does not make it the right technical decision. For an example web devs can relate to, dragging and dropping stuff onto web pages with MS FrontPage was a pretty easy thing to do for a lot of people who had no knowledge of HTML, CSS, web standards, etc. Why should they take the time to learn about all that stuff when they can be publishing their own web sites from the comfort of their WYSIWYG editor? :-)

Of course, I think most web designers with any degree of experience would advise those FrontPagers that if they really wanted to make good pages / sites, they should take the time to learn more about the underlying technology and the other options available to them, knowing that along the way they will learn why FrontPage is evil.

In a similar vein, I would propose that people who are considering building their decidedly non-CMS app on top of WordPress take some time to expand their horizons. Maybe even build an app or two outside of WordPress, explore the other frameworks and lower-level components available for handling some of the stuff you’re depending on WP for (user management, etc.) and then come back and make a more educated decision on the best approach for your project.

This entry was posted in Blog Posts. Bookmark the permalink.

3 Responses to Using WordPress as a Golden Hammer

  1. Dan says:

    IMO: If it helps you build a product faster and provides benefits ( i.e. existing developer community, ease of entry for users, etc.. ) the analogy of a golden hammer, if used, falls short and is just an insult to disparage another developer.

    Another case you’re ignoring: the possibility to abstract the app at any point in the future is fairly easy; if done right, it’s not a re-write ( gets easier the less you use core functionality[1] ).

    It’s also better to release software/applications than talk about it.

    [1] Point being: the further you get from needing the WP core ( which is the basis behind a GH statement ) the easier it is to abstract it and build a standalone application.
    Release early, release often.

  2. JB says:

    I don’t think in most cases it would help build the product faster, unless (like I suggested) there’s just an unfamiliarity with anything outside of the WordPress world.

    It’s not about insulting other developers; it’s about encouraging them to broaden their skillset and acknowledge the fact that their lack of experience is limiting their ability to determine the best approach. That may sound insulting, but it isn’t meant to be; it’s just reality.

    As for the ability to “abstract” the app, I don’t think the fact that it’s seperate enough from the underlying WordPress platform can be used as an argument justifying building it on top of WP. If it is that seperate, then that’s all the more reason not to build it on top of WP in the first place.

    Of course it’s good to release something rather than just to theorize about it. That’s where these patterns come from: analyzing released software and identifying what works and what doesn’t. The large community of software developers (who are regularly releasing software) generally agree that this is an anti-pattern. Based on my own experience (10+ years of developing and releasing software), I agree, and I recognize this for what it is.

    Release early / release often is a good motto, and you will be able to do that far better by avoiding decisions like this that are widely acknowledged to be bad, because they will hinder your ability to do that in the long run.

  3. Otto says:

    I agree with this completely, and have a simple guideline for developers to use.

    - If you find yourself having to “work around” pieces of WordPress a lot, or if you want features to be added to the core that make what you’re trying to do easier but which are not directly related to blogging without your particular plugin, then you shouldn’t be building on top of WordPress.

    Now, that said, don’t eliminate WP from the equation entirely. Rather, instead of thinking of your project as building on top of WordPress, make your project stand alone and then provide a plugin to *integrate* it with a WordPress installation. This will get you better results and keep you within familiar territory.

    For example, I see a lot of people want to create their own special types of pages, where they basically control the output entirely, using some data from outside WordPress, etc. I’d say to try making that stand by itself, then just create a plugin to handle directing WordPress requests to your system when it is appropriate instead.

    Systems that have to work around WordPress’ assumptions often are probably outside of the scope of the project. Create a new project to accommodate them. Branch out. Heck, you might even create a new community around it.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>