For many of us, we spend our time heads down on projects trying to deliver solutions for a customers. That’s a Good Thing™, as far as I’m concerned.

But every now and then, I think it’s also a Good Thing™ to take stock of where we – as a development community are – where we’re headed, and the things that we’re able to observe about ourselves.

Observe where we are

We need to observe where we are (and from where we’ve come).

Now and again, I’ll write about my own opinions about WordPress (the software, the community, the economy, etc.). I don’t always have a direct point, though.

Sometimes it’s just a smattering of thoughts about what I’ve seen. You know, like a digression. And that’s what this post has shaped up to be.

A Digression on the State of WordPress

There’s a constant discussion about the quality of the code that makes up WordPress core. This is bound to happen when you get opinionated people (read: developers) working with 10 year old software.

1. The Quality of Core

For whatever it’s worth, I try to take a realistic stance on the quality of core’s source code:

When it started out, WordPress started as a fork from an existing project. Developers contributed code in the best ways they knew at the time. The project grew, new paradigms entered the code, they mixed with the old code, and that continues to this day.

I know: We’d always like it to be better. That’s something we should strive for, but we need to be realistic about the size of the code base we’re dealing with and all of the moving parts that are in place.

2. An Inconsistent Ideal

It’s not at all uncommon to hear other developers talk about how much they want to see core refactored. I understand the reasoning behind this. Seriously, I do.

I don’t think it’s that simple, though. It never is. My guess is if you were to ask, say, 50 developers what that would look like, you’d fail to get a consistent answer.

Sure, you’d hear things about classes, perhaps something about inversion of control, namespaces, modularity, dependencies, package management, and so on.

You know: The thing the cool kids are using these days.

But would you hear something that was completely consistent across those surveyed?

My guess is no. And that’s because we all come from different backgrounds. And it’s because we often think the way we tackle problems are the best way to do so.

3. Simplicity Is Hard (Stop Oversimplifying the Problem)

This isn’t to say that there aren’t tried and true principles to use (see also: Design Patterns). But it’s to say that it’s never a simple matter of:

Well all you need to refactor is X, Y, and Z and then you’d be good to go.

Software is hard. From designing it (from the database to the UI), to maintaining it. There are a lot of decisions that go into it. Couple that with the nature of open source software and you’ve got something even more complex.

I know: We can all talk air our grievances about what we dislike about WordPress core. It’s so much easier to complain.

I’d like to believe that people complain about the things they dislike because they love the software. Sometimes, I see evidence to the contrary, though. I think some people just want to complain. Sigh.

Furthermore, we can talk all we want about how much we love or hate a new feature that’s coming to core. That’s fine, too. We’re welcome to do that.

  • If you like what’s coming to core, fantastic! Use it in your own work, write about it, and build cool things on top of it.
  • If you dislike it, then don’t use it. Write some custom functionality to disable it, even. We’re all programmers, right? But don’t curtail other people’s excitement.

As I mentioned, we’re all programmers. We have the ability to handle these new features as we see fit for our clients through the use of code, right?

4. It’s Dreaded Software

It’s easy to look at surveys taken on sites like Stack Overflow and see that WordPress [sic] is one of the most dreaded pieces of software to work with.

Most loved, dreaded, and wanted.

Most loved, dreaded, and wanted.

I’m not dismissing this. There are certainly things we can do to improve the software the rest of us love to work with and that powers so much of the web.

You can chalk it up to people not understanding it, you can chalk it up to people not grokking the codebase, or you can seek to learn why others dread using it.

Then you can do what you can to help ease that dread and make things easier for them. Of course, this would require that we understand another person’s problem with the software, grant they may be right, and then perhaps change our own mind.

Yikes!

Maybe I’ve just oversimplified the problem. That would mean that I would have done exactly what I said we shouldn’t do, wouldn’t it?

Anyway, it’s not from lack of trying, though! I blog daily about this stuff.

5. Amazing Things Are Happening

Sometimes I think we get weighed down with the things we dislike about WordPress. That’s natural, as it is with other things in life, but there’s a lot of great things happening right now.

The REST API is merging into core over the next two releases. WP CLI has just received significant funding to help it mature into something more powerful than it already is.

A more RESTful WP-CLI

This is evidence that we want more from WordPress and we are getting it.

So remember, despite all the noise that we see and that we deal with on a seemingly daily basis via Twitter, blogs, and whatever other channels, it’s not representative of the project in its entirety.

WordPress has done amazing things for the web. It’s not without it’s problems – what is? – but it’s pushing forward and it’s getting better and better.

The next time you read some random complaint about a feature or some hyperbolic take on why something is so terrible, balance that perspective out with the good work that’s happening.

And get excited about it. It’s a terrific time to be working with WordPress.

Until Next Time

I know: This post doesn’t have a single, clear point. That’s okay. I never intended it to have one. Instead, it’s more or less a digression of observations and thoughts I’ve had over the past few years.

This isn’t the first post like this and it won’t be the last post like this, either. Sure, I welcome your comments on this topic.

Remember, I have a comment policy and I’m interested in productive comments. Nothing more.

Category:
Articles
Tags:

Join the conversation! 11 Comments

  1. Tom,

    Excellent post. I agree there are great things happening in WordPress. WP-CLI is an incredibly underrated tool. My only problem with it is that it doesn’t come with WordPress.

    The WP-CLI makes working with WordPress far easier; not just development, but deployment and maintenance as well.

    Again, great post!

    • Thanks for the comment, Ryan!

      Re: WP-CLI, I think it makes sense not to include it with WordPress sense the majority of those who are going to use WordPress aren’t going to need the CLI.

      Even still, I’m with you — it and the REST API are two really cool things to have included with it and it’s only going to get better.

  2. Great tempered view on things (as always).

    “I don’t think it’s that simple, though. It never is. My guess is if you were to ask, say, 50 developers what that would look like, you’d fail to get a consistent answer.”

    I love this line for multiple reasons. There’s no question that this would happen. This lack of consistency is normal. It’s software design. Design isn’t about the “one true” answer. It’s about trade offs.

    Put 50 graphic designers in a room and ask them to design a sheep logo. You’ll get a sheep, but none of them will be the same. It’s same idea here.

    It’s a collaborative creative process so personal taste is part of the mix. You have to get to a consensus through the process until all parties are satisfied with the outcome. Or you can just work alone :P

    I say this all the time, but I wish core developers did more software design. I understand a lot of the philosophy for core. The need for backwards compatibility, they want a system they won’t need to rewrite in the near future (or ever).

    These are the design constraints. But why not just do a bit more and make sure you can reuse these new features in new ways. Nacin said a year go that they go “all out” when they rewrite something. It doesn’t feel that way much of the time.

    Why isn’t the REST API routing decoupled so we can use it elsewhere? Things like that. If we’re going to spend so much time to put a system in and then leave it there for years. Let’s just do a bit more so that we can use it elsewhere.

    Same with the collaborative process. I do appreciate that they’re more open with the process now. The whole discussion around the shortcode API was great. Design isn’t behind closed doors as much anymore, but there’s still thing you can do on that front too.

    • It’s software design. Design isn’t about the “one true” answer. It’s about trade offs.

      Agreed.

      There’s no silver bullet pattern, architecture, organization, etc. Sure, some are more ideal than others or some are more suited for a solution than others, but there isn’t one that’s really above all the rest.

      Or you can just work alone :P

      Sometimes that’s tempting.

      I kid, I kid. If that were the case, then open source is absolutely the wrong part of the industry.

      I do appreciate that they’re more open with the process now.

      Agreed! It’s so easy to get frustrated or jaded by something when it’s out in the open, but it beats the alternative. And people who end up being toxic to the discussion shouldn’t be allowed to participate.

      But that’s a discussion for another post, I think :).

      • “There’s no silver bullet pattern, architecture, organization, etc. Sure, some are more ideal than others or some are more suited for a solution than others, but there isn’t one that’s really above all the rest.”

        I think that’s where the design aspect comes in. It’s good (even critical I’d say) to understand the tradeoffs. Even if we look at that “agreed upon” list of features:

        “Sure, you’d hear things about classes, perhaps something about inversion of control, namespaces, modularity, dependencies, package management, and so on.”

        There are different ways to approach the problem within the same community. Laravel vs Symfony vs Aura. Aura is one project I look at often for inspiration because Paul Jones made a unique design decision. He said, “I want my components to have no external dependencies.” He wanted them to be decoupled from other packages.

        This brings with it unique choices that you don’t see often in PHP anymore. It’s so easy to glue libraries together with Composer. Yet someone decided to build routing, IoC, etc without relying on other packages. From a WordPress perspective, this is a good source of inspiration. We need things to be stand on their own because we’ll always be behind the curve in terms of PHP version adoption and things like that.

        And that’s just for Aura. I could go on lol.

        The point is that each framework has made unique design decisions. We can look at those and use them in our own design pursuits. It’s just a question of noticing them and understanding how they fit our context in the “WordPress world”.

  3. “Software is hard. From designing it (from the database to the UI), to maintaining it. There are a lot of decisions that go into it.”

    Let’s not forget that updating software in one place, can break it in another.

    Also I’m no expert on what goes into the WordPress core, so I can’t see myself being in judgement of what it produces. Otherwise, I’ve never had any problems with it and I think it’s come a long way.

    • Let’s not forget that updating software in one place, can break it in another.

      Absolutely.

      This is where unit testing and continuous integration come into play. Sure, that feels like a lot and it might “slow down release time” but the truth is that it saves so much in the long run.

      And I’m glad that there’s an emphasis on testing things for exactly the reason you’ve outlined above.

      Also I’m no expert on what goes into the WordPress core, so I can’t see myself being in judgement of what it produces. Otherwise, I’ve never had any problems with it and I think it’s come a long way.

      I think it’s easy to stand on the outside and talk about what we hate and what we like without giving too much thought as to the rationale as to why something is the way that it is.

      When it’s a codebase that’s over 10 years old, there are going to be things we simply do not like. And that’s okay.

      Perhaps they were fine years ago. Perhaps there could have been better decisions made.

      I don’t know. I wasn’t part of it.

      But I know that the people who are on the core team do care and, over time, it’s not going to sit and simply rot. It just takes time for it to evolve into something more mature.

      Maybe that’s idealistic. Time will tell.

  4. re: “We’d always like it to be better. That’s something we should strive for, but we need to be realistic about the size of the code base we’re dealing with and all of the moving parts that are in place.”

    and

    “Software is hard. From designing it (from the database to the UI), to maintaining it. There are a lot of decisions that go into it. Couple that with the nature of open source software and you’ve got something even more complex.

    I know: We can all talk air our grievances about what we dislike about WordPress core. It’s so much easier to complain.”

    Yes. Exactly!!

    With those point in mind, what’s difficult to understand is why does more and more getting added to core? It doesn’t make sense to take an already sprawling product with plenty of technology debt from it’s lifetime and take on more bigger bites as a way to cure the ills of the small bites in simpler times. It’s as if someone is saying, “Let’s cure cancer with…cancer. Yes! That’s it!!” Whoa.

    Pardon me for stating the obvious. Again :) But put another way: If there is a flaw in the plugin architecture then let’s fix that.

    This is especially true given the REST API. If that ideal is to allow devs to use WP in new and yet unimagined ways, or at least do better with “traditional” WP solutions, then why force so much (read: more and more) unnecessary technology (e.g., responsive images) on ALL installs when at any given movement might only be a fraction of the installs using core feature X? It looks as if the core is looking for trouble instead of focusing on KISS and letting the architecture do the rest.

    Perhaps it’s just me, but when I read complaints about core code, pause and then read between the lines, those complaints are mostly complaints about the core team and it’s heavy handed we-know-best approach (as well as what the mighty Carl Alexander pointed out.) The bloated core code is simply a symptom of broader issues with organizational, culture and/or tradition. Those things aren’t evolving in sync with the market. THAT is VERY frustrating for some.

    Finally, if the REST API is going to (ideally) open the WP door to more devs, presumedly with depth & breadth of technical expeirence, then it’s going to be interesting (to put it kindly) how those market forces (if you will) are going to respond to “The WordPress way.” For that group, WTFPress isn’t that hard to imagine, is it?

    • With those point in mind, what’s difficult to understand is why does more and more getting added to core? It doesn’t make sense to take an already sprawling product with plenty of technology debt from it’s lifetime and take on more bigger bites as a way to cure the ills of the small bites in simpler times. It’s as if someone is saying, “Let’s cure cancer with…cancer. Yes! That’s it!!” Whoa.

      I don’t really think that’s a fair analogy.

      The technical debt that exists within the code base of WordPress (or in any code base) isn’t really analogous to a disease. It’s more, if anything, code rot.

      And sure, adding things to core rather than taking things away from it adds to what’s in the software as it is, but it’s not really attempting to fight back the debt, as it were.

      If anything, it’s just leaving it there.

      I think over time those things will slowly be refactored, but we can’t just continually iterate on parts we don’t like; otherwise, we’ll be on a never-ending cycle of trying to perfect the code base which, as you know, we really can’t do.

      We can make it better. We can make it really good. But if we continue to that that and ignore features, then the software won’t mature.

      So it’s a balancing act, I think. There are things that need to be removed, things that need to be refactored, and things that need to be added.

      Finding that balance is extremely hard, though.

      The bloated core code is simply a symptom of broader issues with organizational, culture and/or tradition. Those things aren’t evolving in sync with the market. THAT is VERY frustrating for some.

      Sure, sure. That’s the nature of people having opinions and, I believe, the nature of open source.

      I do think people could calm down a bit when discussing this stuff, but that’s not my place to regulate, you know? And don’t misread me: I’m not saying lose the passion. I’m just saying be more civil in terms of how the conversation plays out.

      But this issue alone is one that could be discussed until forever so I’m going to stop here :).

  5. “It’s easy to look at surveys taken on sites like Stack Overflow and see that WordPress [sic] is one of the most dreaded pieces of software to work with.”

    WordPress is most comparable to Sharepoint on that list. Having worked with Sharepoint extensively prior to WordPress I much prefer using WordPress and I worked much longer with c#/vb.net before PHP.

    Seeing that they LAMP is also included in the list, then PHP, MySQL, Apache and Linux are also all dreaded. That leaves WordPress in pretty good company.

    • Seeing that they LAMP is also included in the list, then PHP, MySQL, Apache and Linux are also all dreaded. That leaves WordPress in pretty good company.

      I really like this statement :).

Leave a Reply

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