The Embarrassing Nature of Modern WordPress Products

As far as WordPress projects are concerned, I’m far more comfortable talking about projects that I’ve been working on myself regardless of if they are for fun or profit.

And yes, there are times where I’ll share code and other snippets that come from contract work, but I generally do not talk about those types of projects out of respect for the client and/or out of respect for the terms of our agreement.

Contracts, respect, professionalism, and all that fun stuff.

The Disenchanted Young Professional
The Disenchanted Young Professional

But there’s been a project that I’ve been a part of for a few months now, and I received an email last week that struck a chord with me. I asked the client if I could share the quote – keeping them anonymous of course – but use it to try to make a point.

They obliged.

I hate trying to support a theme that’s so dated and broken. I can hardly wait until I can offer support for a theme that I am proud of and is coded well and will be kept up-to-date.

And though it’s already been referenced through a number of different blogs, and the article is already over a week old (which is, you know, practically forever in Internet time), I couldn’t help but think: “We’re ruining WordPress.”

You may or may not think of it as hyperbole, but this is a very real problem.

Modern WordPress Products

At this point, there’s very little to say that hasn’t already been said as it relates to the current state of modern WordPress products. In short, we’re all over the map.

  • We’ve got products that look great, but are poorly built.
  • We’ve got products that look fair, but are well-built.
  • We’ve got products that people are clearly trying to use as a way to make quick money.
  • We’ve got products that people are trying to build to push the limits of WordPress.

So this does raise the question: When we’ve got this much going on within the WordPress economy, how can anyone believe that we’re actually ruining it?

For those of us who make a living off of WordPress – and who care about the features that are going into, say, the next version, or the version after that – then we’re clearly staking our livelihood on WordPress as a foundation for the work that we do.

That’s a pretty neat thing, right?

It means that we believe it’s a foundation on which we can build work for other people such that it solves their problems while also providing us with a satisfying work experience as well as a way to make a living.

It’s a pretty good deal, in my opinion.

But when you hear feedback from clients that includes words such as “dated and broken,” or that exude frustration and embarrassment in phrases such as “I can hardly wait [for a product] I am proud of,” then you can’t help but notice that there’s a serious problem going on in the industry.

Bugs are ways to satisfy customers.

Then again, I know that this isn’t a new problem – this isn’t unique to WordPress, then isn’t something that has just started to happen in software, but for someone who really cares about the work that they do for a living, I will always do what I can to argue against those producing work that contributes to comments like the one shared above.

Forcing a Shift in Experience

As long as I’m involved with WordPress in some capacity, this is something that I believe I am always going to care deeply about. I believe that it is the best platform not just for blogging, but also for content management, and it’s maturing to a point where we can use it as a foundation for web applications.

But, collectively, we’re finding ourselves churning out products that completely ignore the philosophy, disrespect the coding standards, and are nothing more than what amounts to lipstick on a pig.

Sure, there are plenty of themes that look good, but any good developer – or any good engineer – knows that there’s significance in the work that goes into the parts that people won’t see and it does matter that those things are well-organized and architected.

And if you think otherwise, then take stock of the quote at the beginning of this article. When you don’t take care in the work that you’re placing under the proverbial hood, or take care in the work that the average consumer won’t see, they will notice.

It’s only a matter of a time.

Perhaps it’ll be the next update to WordPress, perhaps it’ll be two releases later. But whatever the case may be, if you end up putting together a product and doing so in a way that is motivated more by “just getting something working,” or that is motivated more by making easy money, then the customer will begin to notice as the work will begin to fall apart.

And as sad as that is, it’s as equally sad that we’re giving people that experience with WordPress.

Oh I used WordPress for a project once, but after one [or two] releases, the site just began to break all over the place so we’re opting to use a different platform.

Chalk one up for the bad guys.

We have the ability to create world-class products and high-end experiences for others, yet we’re polluting the air of the economy so much so that people don’t only know what WordPress is capable of, but they don’t necessarily trust it to power their ideas.

No, we can’t get rid of poorly produced products, but we can do a better job of educating clients, taking greater care of the work that we produce, and generally making a stronger effort to build our work in such a way that people are proud of the work they’re supporting and that they’re using.

8 Replies to “The Embarrassing Nature of Modern WordPress Products”

  1. What about the Embarrassing Nature of the Modern WordPress customer?

    Put your pitchforks away — hear me out.

    It’s easy to promote value and support of a “better” theme/experience to the average customer. They don’t do this everyday and they don’t know or care to know about preprocessors — they just want to run their business.

    So who is the modern WordPress customer?

    Perhaps advanced is a better descriptor, but I’d say people like you and me are the modern customer. We have a Github account and we average $125/hr — a minimum project ranges from $3,500 to $7,500.

    So why are we (using “we” loosely here) the first to come down so hard on other WordPress product developers? Let’s use the most basic of examples: Contact forms. (You know what’s coming.)

    Say a client wanted just a basic contact form. Even if you have your favorite scripts ready to go and some basic responsive field styling — it’s probably 3 or 4 hours of work? That’s $375 – $500 to your client.

    Instead we pickup Gravity Forms for $39 or NinjaForms for free. Peanuts! I realize this is a super-basic example, but my point is, the ratio of our retail sale price to our software costs are relatively insane. 10x in this example.

    So why are we the one’s that come down so hard on other product developers in the WordPress space? Shouldn’t we be the customer that understands the value in the software license we’re buying? Isn’t it easier for us to justify the spend for the immediate ROI of a billable project + the future support contract we’re signing?

    I know I’m playing devils advocate here, but this is something I’ve been knee deep in as we all march towards charging the average customer more money for themes.

    Do we look like a hero to the customer when we point our finger to a $25 plugin?
    You: “look what they did to us! They aren’t rolling out a backwards compatible architecture.”
    Customer: “Did you just charge me $10k for that website?”

    Now that was embarrassing.

    1. I found myself in the same place, I was not content charging a client a developer-sized fee for consulting them on what plugins they should use and THEN doing some front-end work. Even if the site looked like a peaceful duck above the water, I knew the problems and anxiety swimming below. I found myself beginning to renounce all plugins unless it was absolutely necessary.

      Unfortunately in my search for an answer to this, I abandoned the WordPress way of theme development and began a form of software/application development that worked… but I don’t think it solves the real problem. Since then I’ve pivoted my ideas towards a more complete solution that considers your thoughts about the WordPress philosophy. Ultimately taking the side Matt (above) mentions, that my customer is other WordPress developers. I don’t expect to use tools that work out of the box, because the solutions my client needs are not in that box. So instead I’m aiming to build tools that equip the developer to their part better.

      The best example of this is ACF. I know front-end (non-developer type) people who can easily understand ACF, use it and provide great user-friendly solutions to customers. Its not a user’s plugin its a developers plugin. I am so sick of talking to developers who charge so much (hourly) and yet have never actually developed a real solution for a client. Make your buck, but charge according to what service you are ACTUALLY providing so that the real developers don’t have to charge an arm and a leg to fix your problems later.

      1. Unfortunately in my search for an answer to this, I abandoned the WordPress way of theme development and began a form of software/application development that worked… but I don’t think it solves the real problem

        I think that this brings up an interesting point, and what I’m about to say is largely based on the fact that, y’know, I don’t have all the facts, but here goes:

        When it comes to pure theme development, I still tend to follow the practices as outlined by WordPress primarily because it’s the standard way of doing it and because it won’t break with future updates.

        That doesn’t mean, though, that I don’t incorporate techniques used in software development such as separating business logic, improving the templating mechanism, and using helper functions where appropriate.

        Ultimately, I really do think it has to do with the solution that you’re providing to your customer. If you’re building them something that’s more of an application, then those are things that we, as WordPress developers, are still exploring.

        But if you’re building a vanilla theme for someone, there’s a relatively standard way of doing it.

        The best example of this is ACF. I know front-end (non-developer type) people who can easily understand ACF, use it and provide great user-friendly solutions to customers. Its not a user’s plugin its a developers plugin.

        I could not agree more.

        I am so sick of talking to developers who charge so much (hourly) and yet have never actually developed a real solution for a client.

        They aren’t developers. I heard a great phrase for this a couple of years ago: They are implementers. It’s just that no one has had the opportunity to educate them otherwise.

        I think some people get all caught up in titles and want to be labeled something for the sake of having the label, which is lame, but it happens. But the work that we all do has got to be able to be qualified in some way – development is just a larger umbrella.

        The problem is that it gives those who care about approaching WordPress from a classical software development background significantly less clout than those who approach is from a more “piece meal” approach.

    2. I know I’m playing devils advocate here, but this is something I’ve been knee deep in as we all march towards charging the average customer more money for themes.

      Playing devil’s advocate, sure, but it brings up completely valid and interesting points. Especially in situations like the one you mentioned (regarding a $25 plugin).

      The thing is that this goes back to two things (at least in my opinion):

      1. What defines a WordPress developer?
      2. Are we going to be artificially inflating prices on themes (and plugins) out of some arbitrary metric?

      As far as #1 is concerned, I think there are many definitions which I hope to cover in a future blog post. But if you think you’re getting someone who builds things with WordPress who has an engineering background, but then get someone who’s better at piecing together a site with a theme, a few plugins, and a maintenance agreement, then it’s going to be a vastly difference experience.

      And as far as #2 is concerned, some people will, yes. But those who understand the worth of what they’re doing understand that this is a shift that needs to happen if people are going to not only be taken seriously as programmers of this particular platform, but as programmers in the industry.

      I know this is more of a tangential comment to what you said in your comment, but you summed it up nicely already so, you know, there’s very little I have to add to that :).

  2. I’ve been around this game for a long time having built my first database driven website in 1995 and I have seen and used many different configurations and languages having decided to move into WordPress last year from Drupal. I agree with Tom that WordPress is maturing and can now be considered as a platform building applications – which is exactly what I am doing.

    For me I think that the key thing is ‘maturing’ and this growing up process is a combination of both customer and the development environment. This is evident in the growing number of large enterprises that are using WordPress such as TIME and the New York Times. At the same time there are millions of individuals with a WordPress install so we are now facing as broad a spectrum as it is possible to get.

    In such a varied and disparate world there are going to be examples of both good and bad. I would also say that there is probably an opportunity here for those who are providing good service to be able to market themselves to those who are willing to customers whose goal is robust and sustainable rather than quick and cheap… In fact that is exactly what I am trying to do.

    1. WordPress is maturing and can now be considered as a platform building applications – which is exactly what I am doing.

      Love hearing this. I’ve done this a few times myself; however, it takes quite a bit of preplanning to really understand how to integrate certain feature sets – be it views or application logic – to connect it to WordPress.

      It’s a foundation, not a framework.

      And until programmers view it as such, it’s always going to cause trouble when the time comes to build things on top of it.

      My two cents, of course :).

      In such a varied and disparate world there are going to be examples of both good and bad.

      100% agree. And it’s not going to change, either. This is the stuff that stays the same, in my opinion

      In fact that is exactly what I am trying to do.

      Keep at it :). And I hope it works out for you (and for the rest of us :).

  3. Preach!

    I can’t tell you how many clients we’ve taken on that have no clue how bad off their sites are. They may look beautiful on the front end but the code and actual content management is a mess. I’ve actually had to show a client that WordPress has a built in media library, that they didn’t need a plugin to upload images and display them. This site had been running for over 3 years and was likely coded while on some form of hallucinagen. While our approach has always been to pare down as much as possible I find that even the worst of sites is no match for the task of actually explaining to the client what the actual problem is.

    Having to dance around the fact that although things seem stable and they are not, telling them we can’t just “toss a contact form up in there”, and that it’s going to take 15k for a custom website is difficult. Especially when your client tires easily of techno speak. Communicating to them what they should expect in value hard, since there is no common sentiment amongst developers that ‘x is bad’ and ‘y is good’, and most of them don’t understand anyway.

    Our creative director sheds a tear every time we get a redesign job and he hears “so when can I pick a theme?”. Folks are used to ready made products. They like that they can buy lasagna at the grocery store from the freezer rather than make it themselves at home from scratch. But have you ever had homemade lasagna? SO much better of an experience! To some that’s worn something, to others it doesn’t matter an iota.

    The market for services and products will eventually separate itself based in those who don’t have the fast food mentality and those that can’t see past fast and cheap. We, as providers, need to make sure we communicate which side of the fence we are on to potential clients and stick to our decision to be the standard. I’m not saying we should do away with plugin purchases for site features and customize all the things, but make individualizes decisions based on what’s right for them. There is a balance to be struck between the ideal deliverable and what’s smart for the budget and client, that doesn’t need to sacrifice quality.

    1. I can’t tell you how many clients we’ve taken on that have no clue how bad off their sites are.

      Isn’t it sad? I mean, they dropped significant cash on something that was put together and really ends up being a mess.

      It’s not their fault, and in some cases it’s not even really the fault of the team who put it together. By that, I mean that they didn’t know any better (not that they should be held accountable for their work).

      While our approach has always been to pare down as much as possible I find that even the worst of sites is no match for the task of actually explaining to the client what the actual problem is.

      Technical communication is a hard thing as it is – having to talk people through how the first iteration of a solution was implemented and why it’s problematic can be even harder.

      Our creative director sheds a tear every time we get a redesign job and he hears “so when can I pick a theme?”. Folks are used to ready made products.

      This is exactly the kind of thing that I want to see a shift in the economy. Granted, people don’t know any better because it’s part of what WordPress facilitates – and that’s great for certain products – but not for things that need custom design and implementation.

      We, as providers, need to make sure we communicate which side of the fence we are on to potential clients and stick to our decision to be the standard. I’m not saying we should do away with plugin purchases for site features and customize all the things, but make individualizes decisions based on what’s right for them. There is a balance to be struck between the ideal deliverable and what’s smart for the budget and client, that doesn’t need to sacrifice quality.

      Amen.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.