In his recent post The Dire State of WordPress, James Shakespeare predicted doom for WordPress if it doesn’t undergo radical architectural change. Henri Bergius followed up with a similar argument in Why WordPress needs to get Decoupled. I appreciate where they are coming from: I can say without hyperbole that Bob Martin’s book Clean Code changed my life (I even had him sign it for me), but as a WordPress developer, I can also say the approach they’re taking is counter-productive.

Bergius advocates rewriting WordPress into multiple, separate software components, and Shakespeare calls for “…a fundamental rethink of the entire platform. We’re talking thousands of man-hours for no direct financial reward… But this doesn’t mean it couldn’t or shouldn’t be attempted.”

There are three big problems with thinking about it this way:

1. Chasing the “grand rewrite in the sky” is typically a recipe for disaster. Being aware of this is a tenant of the Agile approach, where “the boy scout rule” is preferred (leave the code better than you found it, by making continuous incremental improvements). Here’s Bob Martin describing what happens when you have a team still maintaining the old code on a project (since you can’t just abruptly abandon it), and a “tiger team” working at the same time on the grand re-write:
   

   Now the two teams are in a race. The tiger team must build a new system that does everything that the old system does. Not only that, they have to keep up with the changes that are continuously being made to the old system. Management will not replace the old system until the new system can do everything that the old system does. This race can go on for a very long time. I’ve seen it take 10 years. And by the time it’s done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it’s such a mess.

2. Check out Yoast’s infographic on WordPress’ popularity: 72.4 million sites running WordPress, and 20-25% of all new websites are using WordPress. There are over 19,000 plugins in the wordpress.org repository and over 1,700 themes (with probably thousands more not in the repository). With that kind of user base, backwards compatibility and stability take precedence over everything else. Therefore, architectural change must be gradual, low-risk, and backwards compatible.
3. When you’re not actively involved with WordPress, and you’re telling people who live and breathe WordPress development that what they’re doing is awful, it’s hard for that to not come across as antagonistic, and therefore be unproductive. There is a huge community of developers and designers who make their living coding for WordPress, and really enjoy it. While feedback and guidance from outside the community can and should be welcome, one-off prognostications of doom at some vague point in the future are likely to be met with a shrug.

Having said all that, there are some things they’re right about, and there are a couple practical steps forward I’d like to recommend:

1. Bergius observes that he doesn’t see WordPress developers at non-WordPress conferences, and relates a similar observation from Symfony activist Lukas Smith. This fits my experience as well. I see a very real gap between the WordPress development community and the mainstream object-oriented coding community. The WordPress community is big enough that it can get away with being insular – probably every major city in the US (not to mention the rest of the world) has a WordPress meetup group and an annual WordCamp. I’ve spoken at several WordCamps, and a common reaction to my talks is that people are intrigued, and sometimes mystified, that my talks are about various aspects of how to shoe-horn object oriented design into WordPress plugins. I also attend the Philadelphia ETE conference every year, which is the annual tech event in Philadelphia, and I’ve attended various Agile conferences in other parts of the country. Developers in Java, Ruby, C++, JavScript, Scala – you name it – they’re all there, attending each others’ sessions and learning from each other. I’m a gregarious guy, and I have yet to meet another WordPress developer at any of them.

   I can’t speak for other cities, but Philadelphia has meetups for PHP, DevOps, JavaScript, blogging – you name it. There are well over 100 different tech meetup groups in the greater Philadelphia region. And there is interaction between groups, such as the annual RedSnake Philly event that brings together the local Ruby and Python communities. The WordPress meetups are fantastic, but if you’re a WordPress developer, consider getting involved in the broader community. There’s lots of good stuff out there!

2. One of the reasons WordPress is so successful is that it’s such a great platform for hacking. You don’t need a degree in computer science or years of experience to get started with it, and once you learn some basic techniques and WordPress best practices, you can be productive and successful with it. So even if a huge rewrite was a practical idea, it would be a really bad idea to introduce an architecture with many layers and abstractions, as it would make the barriers to entry too high (and if someone wants to use a full fledged web development framework, then they can use a framework – WordPress doesn’t need to become one).

   However, I strongly feel that the WordPress architecture needs to become more open to modern object-oriented design practices. In my previous position at the University of Pennsylvania, I hired many developers, and interviewed some who primarily had WordPress experience, and it did not prepare them well for working outside of WordPress. They had acquired habits they needed to un-learn. I’m talking about routinely using global variables; using classes only as giant buckets of vaguely related functions; using constructors for more than just initialization; etc. As far as I know, these are design practices you really don’t see anymore in well-established development environments, except WordPress.

   The WordPress architecture forces awkward design choices for developers trying to take an object oriented approach. It drives them to use Singletons to deal with all the global state (a choice I can understand but disagree with). It requires a laborious setup to do automated testing (and even after you set it all up, you still can’t do unit testing – you’re doing integration testing). In general, it forces a style of development that is very particular to WordPress, as opposed to an architecture independent style that can be commonly applied to other modern development environments.

   The complaint that learning object oriented design is too hard or not worth the trouble doesn’t make sense to me. WordPress developers learn all kinds of arcane and complex practices to be successful with it. Why not instead make WordPress more compatible with mainstream development practices? Then learning those practices will allow you to be successful with more than just WordPress.

   I understand how and why WordPress evolved the way it did, but I haven’t yet heard a compelling reason why the approach taken to its architecture should forever remain apart from the practices of the mainstream development community. Backwards compatibility can be provided while gradually shifting the organization of the core code.

   The key step that needs to be taken is providing better encapsulation. Here’s a simple example in PHP for moving away from globals but still providing backwards compatibility (more than just that would be needed to getting a handle on all of WordPress’ globals, but with some planning it should be feasible). For hook and filter functions, they could become thin wrappers for instance methods (through the use of an injection container you can avoid unneccessary re-instantiation of objects). Doing these two things would provide backwards compatibility (so nothing breaks, and hackers can still hack), and at the same time would open the door to decoupling, real unit testing, and object-oriented design (without needing to argue about Singletons).

The WordPress community is big and vibrant. Philly WordCamp 2011 was the first WordCamp I attended, and I was thrilled by all the energy and enthusiasm. But from what I can see, WordPress has isolated itself, both as a community and as a web development environment. I don’t see a benefit for anyone in perpetuating this situation, and I see lots of potential benefits for WordPress joining the mainstream development community.

I’m speaking at WordCamp Nashville in a few weeks, where I’ll touch on some of these topics, and I’m happy to discuss this further with anyone interested.