The Technical Qualities of WordPress (Or Lack Thereof)

Last week, I asked if those of us who are involved in the WordPress community if we are really open source pragmatists. This came from a quote that’s been posted, shared, discussed, and so on for the last couple of weeks or so.

There’s one sentence included in the quote that people don’t seem to be discussing and that is are odds with the reputation WordPress has.

The quote (emphasis mine):

The pragmatist values having good tools and toys more than he dislikes commercialism, and may use high-quality commercial software without ideological discomfort. At the same time, his open-source experience has taught him standards of technical quality that very little closed software can meet.

But few can argue that the application has a reputation having a less-than-stellar codebase which can easily call into question the technical qualities of WordPress.

In fact, some believe that it’s “developed wholly by monkeys randomly hitting keys on the keyboard,” and there are discussions that crop up on various communities – like Hacker News – about the poor quality of the codebase.

The purpose of this post is not to belittle the codebase of WordPress. For what it’s worth, I think that it has its good parts and that it has its bad parts, and – like all software – can be compared to a living organism where it’s always changing, and, ideally, the bad parts will mature over time.

But what I’m more concerned with right now is has WordPress taught us standards of technical quality that “very little closed software can meet?”

The Good News and The Bad News For WordPress

When it comes to talking about something like this, I can only speak in terms of my own experience. I’ll try to provide a concise, balanced breakdown on what WordPress has taught me.

I’ve come from both sides of the software world, too: I’ve done closed source software, and I’ve done open source software, and I’ve worked on both for about the same amount of time.

So with that said, here’s what I’ve observed:

The Bad News

I always like to give the bad news first, so the good news can soften the blow :).

But seriously…

  • The core WordPress codebase has a reputation of poor quality
  • The barrier for entry to writing plugins and themes on top of WordPress is set low, so quality appears to be less of a factor
  • The community has fierce debates in which people – rather than ideas – are often left as collateral damage
  • Despite the fact that we have coding standards, we don’t always respect them in core or in products built on top of WordPress.

There are other things that I’m sure others can contribute – after all, we’ve all had different experiences – but these are the top four things that I’ve observed from a high-level in my time with WordPress.

The Good News

Of course, there’s also a handful of a good things that come from working with WordPress, as well:

  • The open source nature of WordPress allows us to improve the areas that are of poor quality. We can make a bad thing good and a good thing better.
  • If you’re an experienced software developer, building things for WordPress can be done so using good engineering practices
  • WordPress has bred meetups both at the city level and at the local level where fellow bloggers, designers, and developers can meet up.
  • People of all types can contribute to the overall project, not just code, but documentation, etc. as well.

Again, this is just a brief (read: very brief) summary of some of the high-level points, but it’s what I’ve experienced during my time with WordPress.

The Technical Qualities of WordPress

In short, I’m extremely skeptical as to if the open-source experience of WordPress can truly teach a developer more than closed source software.

I don’t really see this as a function of the software itself, so much as the community around it. And as long as we’re busy fiercely debating topics of our favorite application (a good thing), we’re doing so in such a way where others are getting scathed in the process (a bad thing).

The core application is filled with both good and bad practices both of which can do a good job of teaching technical qualities, but I don’t know if it does beyond those who already know how to do it. Furthermore, the danger is that you can end up leading budding developers down the wrong path, or turning experienced programmers away.

Optimistically speaking, I think experienced developers stick around to make the core product better, but the risk is still present.

Finally, the technical quality of the software can also teach others how to write, through documentation, and can teach others to collaborate as part of a distributed team which are both skills that are becoming increasingly important as time goes on.

But just as people are determining whether or not they are open source pragmatists, I’d love for us to also consider if the open source nature of WordPress truly does teach more than closed source software can meet.

As the state of things are right now, I think the jury is still out.

14 Replies to “The Technical Qualities of WordPress (Or Lack Thereof)”

  1. Opinions on the quality of the WordPress source do often come up in a negative light, and because I am a pragmatist, it annoys the hell out of me. The impression I get is that some programmers get this idea in their heads that OOP is the “One True Programming Paradigm”, and anything else (i.e., procedural style programming) is crap. That’s just closed-minded, in my opinion.

    OOP is certainly a useful model for helping to organize code, and it offers many advantages to help you code more cleanly. But that doesn’t mean you have to use it for everything, if the language you are using doesn’t force you to.

    In the context of the WordPress codebase, it’s important to remember a couple of things: 1) it started from the b2 codebase, and 2) it’s 10 years old, and has maintained a very high degree of backwards compatibility for plugins and themes over that time.

    10 years ago, the support for OOP in PHP (version 3.x) was at a much lower level than at is now (version 5.3+). And until recently, WP had committed to supporting certain older versions of PHP. Because of that commitment, it would have been very difficult to rewrite large portions of the codebase to be more object oriented and retain compatibility across the wide range of platforms it supported.

    Some people seem to think that the WordPress devs should just “start from scratch” and rewrite the whole codebase with a more modern programming mindset (c.f., Habari. That is not a task that could be undertaken lightly. Large-scale changes of that sort would risk introducing new bugs, breaking backwards compatibility, and would likely take many thousands of man-hours, which could be better used to improve the project incrementally, as has already been done over the past 10 years.

    If you really go back to the beginning of the WP codebase, and compare to today’s version, you see many places where OOP is used, where it makes sense. Many new features start out with reusable/extendable classes, and many older features have been converted to OOP, with compatibility shim functions available.

    Is the WordPress codebase perfect? Hell no. Does it work? Hell yes! Is it “bad”? I don’t think so, because I’m a pragmatist, not an idealist. I think it strikes a great balance, really. The plugin/theme API, because it is not OOP-oriented, is much easier for lower-level devs to grasp. Some idealists view that as a bad thing, because these same “lower-level” devs are likely to write “bad” code. I view it as a strength, because — how many people have I heard say “I learned PHP programming because of WordPress”?

    And you know what? Every one of those idealist “good” programmers started out as a “bad programmer”, and became “good” through experience.

    1. There’s very little for me to add to your points primarily because I agree with a significant portion of it:

      I don’t believe that there is a one true paradigm that’s the holy grail for computer programming.
      There are tools and languages that are more apt for certain problems, but even then I don’t have as big a problem with PHP as some do (or JavaScript for that matter) because I can avoid “bad parts” and write good code – or try to write good code – using parts that I know are good.
      WordPress’ scalability cannot be underestimated. This is something that seems to be glossed over when the quality of the codebase is discussed, but I think there’s a lot to be said for how it performs.
      I’ve never seen a codebase age elegantly overtime.

      I rarely see discussions occur – and maybe I’ll bring this up in an article – about the quality of the products that can be built on top of WordPress. There’s something to be said for a solid architecture of one paradigm that supports plugins, extensions, and add-ons using different paradigms both of which can be written and built elegantly and in a maintainable fashion.

      Finally, this is not to say that development should stop on improving WordPress’ core – I think there’s always room for improvement in software, but there’s also backwards compatibility, PHP version issues, etc, etc, etc, that must be considered; otherwise, you’re going to just break an entire economy which we’ve seen happen with other frameworks that I don’t care to name right now.

    2. I think Doug’s comments are stellar. Particular this:

      I don’t think so, because I’m a pragmatist, not an idealist. I think it strikes a great balance, really.

      And one thing I’ve noticed, there was no discussion of context of the competition. The only option on the market right now that I’ve read about that seems pretty good is Concrete 5, but I haven’t even tried it. The only other popular ones I know of are Drupal and Joomla and those are absolutely laughable in my book — pitiful in their approach to things.

      If you look at the fact that writing a CMS is VERY DIFFICULT and put WP next to what else is out there, I’d say WordPress is freaking stellar and amazing. But I say that primarily having come from Drupal and absolutely hating its idealist over-engineered approach to things.

      1. The only option on the market right now that I’ve read about that seems pretty good is Concrete 5

        Maybe I’ve been under a rock (and not realizing it), but this is the first I’ve actually heard of this particular CMS. Definitely gonna look into it if for nothing else that just to familiarize myself with the options that are out there.

        If you look at the fact that writing a CMS is VERY DIFFICULT and put WP next to what else is out there, I’d say WordPress is freaking stellar and amazing. But I say that primarily having come from Drupal and absolutely hating its idealist over-engineered approach to things.

        With comments like this, you’re bound to find a lot of back and forth on this. Although I’m a huge fan of WordPress – clearly :) – there’s a lot who aren’t and who make their opinions known.

        The thing is, their opinions aren’t totally offbase, either. It’s just a matter how well they present them. But that’s a topic for another discussion :).

  2. I agree with the previous commentator. Once upon a time I ended up as instrumental in killing a big software engineering project because despite the existing spaghetti code, buying new fast hardware made it fully useful until the end of its lifecycle.

  3. I think the thing that programming purists are totally oblivious to, and many of us who advocate for the “WordPress-ish” way may not even recognize when defending WordPress is that there is not one best objective way to architect software and that WordPress’ architecture optimizes for other things besides architectural purity.

    Unlike a Java, C#, Ruby, Python Objective-C, Perl, Haskell or other professional programming languages, or even PHP used by professional programmers, WordPress’ architecture if first optimized for approachability, for ease of development and learning. A large percentage of WordPress developers have the job title “designer” or “writer” and many others have the role of “small business owner” and/or “entrepreneur.” If WordPress were more classically correct, those types of people couldn’t and wouldn’t use it.

    None of the titles/roles I just mentioned are professional programmers and thus one of WordPress massive strength is that it can be learned and can be programmed by people who don’t live and breath programming best practices 25 hours a day. Given that WordPress scales to 17% of the web, it seems the WordPress architecture has been pretty damn spot-on for its apparent target user base.

    I wouldn’t change a thing about the WordPress’ architecture and I don’t apologize for it.To do so would be to throw the baby out with the bathwater.

    1. WordPress’ architecture if first optimized for approachability, for ease of development and learning.

      This is the first time I’ve heard this. You make it sound as if the earlier developers set out to write the application with education of other developers in mind. Is that true?

      This is an honest question because (a) it’s the first I’ve heard of it and (b) if so, I had no idea. I’d definitely respect it, though. I think we rarely see software written with that approach in mind – I know that I don’t do it :I.

      If WordPress were more classically correct, those types of people couldn’t and wouldn’t use it.

      This is a stellar observation. I’d not considered this at all. Good point.

      I wouldn’t change a thing about the WordPress’ architecture and I don’t apologize for it.To do so would be to throw the baby out with the bathwater.

      The only thing I’d change are the things I mentioned to Dougal. I think there are some points that could be refactored, but not necessarily thrown out or drastically change simply to meet the needs, desires, or wants of a design pattern purist.

      1. I think there is some truth to Mike’s observations. I don’t think that educational value of the code is a primary goal, BUT, there certainly has been a lot of effort over the last 4 or so years to improve the internal documentation/comments, to organize code, and to stick to the code formatting guidelines. And those things certainly help a lot when you have to dig through the source to see how something works.

        And also, yes, if the code stuck to a more Ivory Tower coding model (strict OOP/MVC structure), it would make it much less approachable, and scare off a lot of the people I mentioned above — the ones who made the effort to learn some PHP in order to do their own code fiddling.

        Early in the history of WordPress, Donncha championed the use of Smarty Templates for the theme layer. Ideologically, a great idea because it helps keep business logic out of your view layer. But it also limited a lot of things you could do in a theme (or at least, made it more difficult to do certain things). The decision was made to just use PHP as the template layer, and keep it as simple as possible by using helper functions like the_post(), the_content(), etc. The helper functions help keep the template language accessible for non-coders, while still allowing more advanced users to do anything they need to do.

        Good decision? Bad decision? It’s subjective. From a code purity perspective, it’s bad practice. From a practical ease-of-use perspective, it’s great.

        1. I think it was a great decision. Using PHP and _”template tags”_ meant that designers could start unintimidated and then slowly grow their development skills over time as desired and never run into any major hurdles that would put them off WordPress (which contrasts with Drupal, as I’ve discussed with you face to face before.) The fact that designers found it a great platform meant that WordPress was the first platform to truly bring together both developers and designers. And look at the success that it has achieved from that? :)

        2. There certainly has been a lot of effort over the last 4 or so years to improve the internal documentation/comments, to organize code, and to stick to the code formatting guidelines.

          Definitely – and with the recent effort of trying to get a lot of the WordCamp talks on WordPress.tv, this is only increasing.

          The cool thing is that the WordCamps are now offering various “tracks” so many of the talks are now available for bloggers, developers, designers, and so on.

          Love that, too.

          Early in the history of WordPress, Donncha championed the use of Smarty Templates for the theme layer

          Man, I remember using Smarty for a project back in college. How about that.

          And yeah, I tend to be one of those that’s a fan of separating logic (and I think it’s evident in other posts I’ve written as well as in the Boilerplates, but I think there’s a balance to be struck between strictly adhering to a pattern or architecture and locking yourself out of functionality.

          Personally, I’m a fan of MVC, but I don’t preach that gospel to WordPress because I’m also a fan of the WordPress hook system (being pub/sub) because it works well, too.

      2. This is the first time I’ve heard this. You make it sound as if the earlier developers set out to write the application with education of other developers in mind. Is that true?

        I didn't mean to give that implication, and I actually don't know the exact history so I couldn't honestly say; @Dougal would be much more capable of commenting on WordPress' early history than I.

        Instead of viewing it as intention I view it as merely the outcome of the collective decisions that have been made over the past decade and am recognizing it as such.

        I think we rarely see software written with that approach in mind – I know that I don’t do it :I.

        Maybe you are just not aware that you see it. :) My team, or at least myself and one other make our primary architecture decisions based on these tenants. We have a shorthanded for it; we call it "WordPress-ish." :)

        This is a stellar observation. I’d not considered this at all. Good point.

        Thanks for the emphasis, but I can only say I've lived through the rise and fall of two prior developer tools ecosystems so let's just say at this point the pattern would be pretty obvious to anyone.

        I started my programming career (vs. my educational background) with dBase and quickly graduated to Clipper, both on DOS (this was 1987.) Later I wrote a book about Clipper 5 which had evolved to be an awesome programming language. Unlike dBase and Clipper's nemesis-at-the-time FoxPro you could practically do anything with Clipper, or so it seemed. And I, being the idealistic young programmer I was at the time thought Clipper was light years better than FoxPro even though FoxPro had a larger user base. Those stupid FoxPro fools, they just didn't know how coding should be done correctly ya know?

        But Clipper died thanks to the rise of Windows and with the growth of Windows so grew Visual Basic. Now Basic was known as a little shit of a language and we all know that real programmers programmed in C++; as such there were many things you just could not do with Visual Basic. Funny thing was, people who "didn't know any better" were flocking to Visual Basic like white on rice. And they were getting real work done! Hmm…

        I was running a catalog mail order company at the time selling Visual Basic components and I was playing marketer, not programmer so it was easy to overlook the "inferiority" of Visual Basic. But watching my customers I came to the epiphany that maybe just maybe Visual Basic's (and FoxPro's) supposed weaknesses were actually great strengths.

        The more I considered it the more clear it became; because both FoxPro and Visual Basic were approachable and didn't demand too much of their developers. Consequently more people could become developers and more people could build things that they needed a developer to build. And at a time Visual Basic was the most widely used programming language in the world.

        Fast forward a bit and Microsoft released .NET which included VB.NET. VB.NET was almost on par with C# so finally VB developer would not be held back! But guess what happened?

        All of VB's wannabe "testosterone developers" (you know the ones, those who beat their chest about how everything needs to be done "correctly") left VB.NET for C#, and for the remaining userbase VB.NET was simply too complicated and, well, guess what language is not even close to being the most widely used programming language in the world anymore?

        WordPress as a development platform parallels the early Visual Basic down to their extensibility; WordPress has hooks and VB has events; they are pretty much the same thing. If the core WordPress development team were to heed the call of those who say it needs to become MVC, fully OOP and/or follow programming "best practices" then it would signal the beginning of the end for WordPress' dominance on the web. But fortunately I don't see the core team going down that path in the foreseeable future.

        Forgive me for using this but I just have to:

        "Those who are unaware of the past are doomed to repeat it." :)

        I think there are some points that could be refactored, but not necessarily thrown out or drastically change simply to meet the needs, desires, or wants of a design pattern purist.

        Oh, absolutely. I was being hyperbolic to make the greater point. There are many individual things that could be improved as long as the core architecture stays in tact and as long as things remain "WordPress-ish" :)

        P.S. One thing I hated when I came to WordPress but now I question my own prior views are functions with hundreds or thousands of lines of code, e.g. code in WP_Query. If that had been architected as an object with lots of tiny methods as purists would advocated (and in the past I would have been one of them) then the entire structure would have been fragile and much harder to evolve without breaking anything.

        While I don't think really long functions works for most projects and development teams given that WordPress collectively has one of the largest development teams in the world, if not the largest, the size of that team combined with it's passion can reign in a lot of the downsides that "best practice" code organization aims to manage. What's more WordPress gets to avoid the often unspoken downsides of following those best practices, i.e. complexity and fragility during code evolution. IOW, WordPress occupies a unique position in history and as such the rules don't all apply to WordPress, relativity speaking (pun intended. :)

  4. For the most part I agree with the views here. I am a relatively experienced programmer although self taught. I’ve never been force fed OOP in College/University. Rather I’ve evolved my understanding by looking at a large number of languages including C++, but also more obscure ones like Lisp.

    In my opinion programming paradigms have use cases however none of them are universally perfect. I don’t care for languages like Java or C# that force a single ideology.

    WordPress works well as it does not force a single idea. The plug-in system can be extended with objects or MVC in larger projects(there are plug-ins to do so) however it’s also very simple to hack simple projects (a few hundred lines of custom code) and get them out the door rapidly. In these cases excessive structure would be a waste of effort.

    On the whole I don’t have much love for traditional oop on the server side. Page handlers are essentially functions which transform an input (url/post data) into an output (HTML). It’s easily adapted to a semi or purely functional approach. If I was to start a big project I’d lean towards that.

    1. In my opinion programming paradigms have use cases however none of them are universally perfect.

      Agreed. I like OOP because it tends to mesh well with how I think about programs in my head, but I’d not stand up in front of an audience and say it’s the ideal paradigm.

      Same for MVC or MV* or whatever the hot new design pattern is right now ;).

      The plug-in system can be extended with objects or MVC in larger projects(there are plug-ins to do so) however it’s also very simple to hack simple projects (a few hundred lines of custom code) and get them out the door rapidly.

      True! It uses the event-driven pattern for event registration, but in addition to that, you can really structure your work however you want. This mindset of not mixing patterns is one I don’t really understand (in terms of where it started), but I like being able to know how to register things with WordPress and then integrate that with my preferred solution.

      Page handlers are essentially functions which transform an input (url/post data) into an output (HTML). It’s easily adapted to a semi or purely functional approach.

      I see it being either/or. I mean, some procedural code to handle input and can be done with a few set of functions but the nature of the solution may result in a lot of files or a lot of functions.

      When that happens, I like OOP. But I also try to make sure I’m pragmatic about what I do — that is, I won’t do OOP for, say, a single function or something. That’s a bit overkill :).

Leave a Reply

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