Last week, I published my thoughts on Software Craftsmanship and WordPress. For what it’s worth, that particular post was one that I’d been thinking about for quite some time, I just never took the time to sit down and actually draft my thoughts on it.
The post resulted in a short, but interesting discussion both in the comments and on Twitter, but one comment in particular really got me thinking more about the topic.
Seeing the terms “WordPress” and “software craftsmanship” in the same sentence makes me LMAO. I just downloaded 3.5.1 to see if it was as bad as I remember. It’s worse. I remain convinced that WordPress was developed wholly by monkeys randomly hitting keys on a keyboard.
The point of this post is not to go back and forth on whether or not the author is correct in his statements. Instead, the comment got me thinking about craftsmanship in the context of the work we do on top of pre-existing systems regardless of the language, platform, and/or framework that you’re using.
Specifically, it got me thinking more about quality WordPress products and projects and whether or not form follows foundation.
A Foundation For Web Application Development
First, I’ve shared my opinions in numerous posts on using WordPress as a foundation for web application development:
- My Thoughts on Building Web Applications with WordPress
- WordPress For Application Development
- Why WordPress Isn’t Viewed as an Application Framework
- Using WordPress For Application Development
I reference these for those of you who are stumbling across this article, who are just getting into building applications with WordPress, and to provide a little bit of background as to the amount of time I’ve spent thinking and writing about this.
In retrospect, perhaps it’s too much time ;).
Anyway, back on topic.
One of the great things about WordPress is that it’s built by people all over the world thanks to the nature of open source. But the point of this post isn’t to offend or defend the actual quality of the code of the WordPress application.
Instead, it’s more about the quality of products that are built on WordPress. I recognize that, with any platform, it’s easy to argue about the quality or lack thereof of products built on top it.
You can make a statement, do a quick Google search to pull up results to back up the claim, and then have your case. But come on: finding a handful of poorly built products doesn’t do anything build a case against the products that exist of high quality.
Simply acknowledging that negatives exist without acknowledging the positives isn’t an argument.
Foundations May Influence, But They Don’t Define
But it comes down to this: The foundation on which something is built doesn’t always negate the quality of things built on top of it.
Whether or not WordPress has a low-quality codebase does nothing to deter other developers (or myself) from writing clean, well-organized, readable, and maintainable code that also effectively and elegantly solves a problem for someone.
Furthermore, there’s always going to be work to be done on software. Sure, we can do a number of things from the project outset to make sure we engineer a solution the best that we can, but the deeper we get into solving the problem using code, the more likely it is that we’re going to find that we’ll need to refine, refactor, and re-organize some of the components of the application.
If this wasn’t true, we wouldn’t have half the strategies, design patterns, refactoring techniques, and testing tools that we have.
Ultimately, the quality of foundations and frameworks are one thing, and though we should work to make sure we’re building those with the highest level of quality possible, the same is true for building products – including quality WordPress products.
It’s just that the foundations on which we’re building our products don’t fully dictate the quality of code that we’re writing on top of it.
Agreed. I catch a lot of flak from my co-workers about building everything on WordPress. I fully realize that the codebase is terrible, but personally I feel that the Plugin API negates that entirely.
WordPress is experiencing a huge amount of success for the same reason that Firefox did: plugins. Developers and others who are regarded as experts in a field will recommend tools to friends and family that they use personally. I love WordPress to death, but I can’t help but to feel that “Chrome” is on its way.
Here’s something that I always come back to: Do we – as developers – inherently assume that closed source software has an elegant codebase? It’s easy to love on what we don’t know (the whole “ignorance is bliss” thing) than it is to simply improve whatever it is we’re complaining amount.
Tom, that’s a good point about closed source. A lot of it is tragic to look at and more or less not salvageable (that’s what Qualcomm decided about the very popular Eudora email client: I’d paid for it and would have kept paying for it).
Still shouldn’t WordPress core be working on rewriting all of core to modern PHP standards (I don’t blame core for the old mess, PHP coding has improved enormously over the last ten years), rather than on destroying the menu system (a sample controversial initiative you cited)?
Indeed. I remember Eudora back in the day, too – I used it as my primary email client until other options came along. Even still, it was a good piece of software early on.
First, I completely understand your position. I don’t know if I agree with it because I’ve yet to come to a conclusion as to how I feel about the menu system being in the Customizer.
Don’t get me wrong: I’m not trying to be lazy or to skirt the issue around it, but it’s one of those things where I’m trying to think about the implementation from the data model all the way up the stack to the user interface. I absolutely get the frustration around it.
But asking if the core team should be focused on the menu system or the core code seems like a false dilemma to me. Here’s why: With a team of core contributors and volunteers that are available to work on WordPress – at least as it stands right now – I think that there’s enough work to go around such that these things could be worked on in tandem.
I know in saying something like this, there’s plenty that could be said back in terms of how much I may not understand in terms of managing a project, or dealing with open source, or how large WordPress is, or any of that. It’s a lot of assumptions, but I’m also not going to pretend I know how to manage a 10 year old project, either.
All that to say, I don’t think it’s an either/or situation. Additionally, with WordPress’ commitment to backwards compatibility, I think that there would need to be more work done than just bringing the core code up to more recent standards. I don’t know of any other way other than almost making two editions of WordPress – one that supports legacy hosts and one that supports newer hosts.
Anyway, I’m going to stop here – I hope I’ve been clear enough in the comments. I know it’s been a bit of me rambling on about it, but I didn’t want to neglect any of the [good] points you’ve made.