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.
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