I enjoy talking with fellow developers about the problems they are thinking about as it relates to their field, and the problem spaces in WordPress is no exception.

That is, I enjoy hearing about what they are working on, what they are thinking about, or what they are tinkering with as it relates to their primary line of work.

Tinkering

For many who read this blog (and this includes myself though I’m the one actually writing it), we spend a lot of our time working within the WordPress space but does mean we spend a lot of time thinking about the WordPress space? Furthermore, does this mean that we spend a lot of time thinking about problems and potential solutions to what we see in our area?

First, this is not something that’s unique to our space. I believe that you can find this in any programming community.

Secondly, I think that this notion of thinking about a particular set of problems is something that’s a bit more abstract than what we usually discuss or see written about on other blogs.

The Problem Spaces in WordPress

For example, many of us are used to thinking about how to solve a problem whenever a customer brings us a set of requirements. They want us to build whatever feature they’ve specified. We spend time thinking about it, solving it, testing it, and then releasing it.

Similarly, many of us also think (and some often complain or voice concerns) about features that are potentially going into WordPress core or that are adding functionality to a pre-existing feature (such as The Customizer).

Although I think these are important discussions to be had, I’m not really referring to them in this post. Like I said, I’m thinking about a space of problems that exists at a slightly higher level of abstractions.

A Digression on Computational Theory

I know, the heading sounds like one big snore-fest, but it’s about the topic at hand, so it seems worth covering. So hang with me.

When I was in school, I had to take a class in Computational Theory. For the most part, I’m more of a fan of practical application, but I know that much of said practical applications are the concrete implementations of proven theories.

Computational Theory

Here’s the thing: Studying theory is something that may be exciting (admittedly, for some more than others). At the core of computer science, it sits at the intersection of math and machine capabilities (or, more generally, programming) and the various types of problems that exist within that space. And this is a very, very broad space.

At one end of the spectrum, one set of challenges may include the amount of time it takes to traverse a data set such as a tree or a graph of a certain size when you have a starting path and are looking for, say, an optimal point to a destination in the data structure. These problems are solved (how do you think your favorite maps application works?).

On the other end of the spectrum, there are these whole other sets of problems that are not solved. These are known as NP-complete problems. If you’re interested in the topic, feel free to read more about it.

But what does this have to do with WordPress?

More Abstract Problems in WordPress

As with any programming environment, there are unique sets of problem spaces in WordPress that are fun to think about even if there’s not yet a clear to implement them.

I take that back. Let’s put it this way:

There are a variety of ways to achieve a given solution (this is the nature of computer programming, after all), but the most optimal solution may not always be the easiest to find.

Right now, there’s an entire group of people that are thinking about:

  • How to properly handle package management as it relates to WordPress,
  • Fighting the tension as it relates to using WordPress to create terrific solutions while juggling the hurdles of backward compatibility,
  • Thinking regarding more modular programming such that we can bring in libraries through things like wppackagist and not break an entire installation,
  • Reliable ways to handle repetitive tasks that we see as it relates to bootstrapping plugins,
  • Handling the case of testing anonymous functions,
  • Fighting the good fight against more recent features of PHP and legacy versions,
  • And other things that are even still more abstract.

Sure, some of these may be more practical than others. But the point I’m trying to make is that the way we think about WordPress doesn’t always have to be relegated to existing features, feature plugins, debates, and other things that may be going into the core application.

The Problem Spaces in WordPress

If WordPress is a sphere, then there’s an entire set of rings or perhaps even an atmosphere of other problems that are sitting slightly above the core application that many people like to think about not only for the sake of just thinking about but for the sake of improving development for all who all interested.

Rambling On

I don’t know if this post strikes you more or less as an unfocused smattering of things somewhat related to WordPress, or if it strikes a chord with you. Or maybe it seems completely pointless.

Whatever the case, what I know to be true is this:

  • WordPress is a program
  • Programs are based in computer science
  • Computer science is rooted in computational theory
  • Thinking through problem spaces in WordPress is natural to computational theory, but computer science, as well.

In a future post, I hope to talk about some concrete examples as to what constitutes problem spaces in WordPress because I still feel dissatisfied with my attempts in this post. But for the sake of at least starting to share my thoughts on it, I thought it would be worth sharing some initial thoughts than nothing at all.

I know some of you are out there because we’ve talked at WordCamps, via email, on Slack, and so on. So please, feel free to chime in and comment on this.

Finally, if you specifically have any thoughts one way or the other about any of this either directly related or tangentially related, I’d love to hear more about them in the comments.

Category:
Articles
Tags:

Join the conversation! 5 Comments

  1. Hey Tom,

    Very interesting article, and certainly amongst the more exotic ones in most people’s WordPress feed.

    I myself love to flex my thinking muscle to solve more abstract problems. I also tend to approach problems by wanting to find a generalized solution first, before trying to apply it in a special-case form to the specific problem at hand. This is an approach that I find very valuable in development, as it allows me to avoid architectural “dead-ends”.

    When you’re new to programming, just getting stuff to work without it exploding is the challenge. And challenges are what keeps us motivated and where we get our gratification from.

    With growing skills and experience, your perception of what constitutes a challenge will slowly drift more and more into the abstract. You’re not satisfied with having stuff work, you want to know that it will work now and in the future, and you want to know that you’ve considered all of the relevant approaches and found the best one. And in addition to that, you want to know that you’ve solved the right problem in the first place, as I’m sure everyone can tell stories of building a brilliant solution to the wrong problem.

    In the end, it is not very difficult to get the computer to do some specific steps. What is difficult is knowing what will be the eventual implications and consequences of the changes you’ve made if you multiply them by the different installations that are out there and project them into the future.

    You’ve listed some of the current “bigger” problems in WordPress development, and for each of these, the time dimension also plays an important part. That’s what makes it so difficult and time-consuming for a large project like WordPress to make larger changes.

    In all of this, computational theory can be a big help. It is sometimes very difficult to reason about the practical limits of a given algorithm. But most of the time, you can quickly find the theoretical limits… If you have a theoretical certainty that something does not work, you can immediately skip the practical tests.

    The theory also allows us to quickly find the edge cases, so that we can precisely test these, without wasting time doing tests that cannot provide conclusive results.

    And for most of what we’re developing, computational theory can already let us estimate how it will scale with volume, without having coded a single line. This is important when you’re trying to avoid building performance bottlenecks that you can’t get rid of later on.

    Yay to theory! :)

    • Very interesting article, and certainly amongst the more exotic ones in most people’s WordPress feed.

      Haha, is that a good thing? Who knows — it got a long comment out of you in particular which I consider a plus so I consider it a win :).

      I myself love to flex my thinking muscle to solve more abstract problems. I also tend to approach problems by wanting to find a generalized solution first, before trying to apply it in a special-case form to the specific problem at hand. This is an approach that I find very valuable in development, as it allows me to avoid architectural “dead-ends”.

      I don’t know if this is learned or innate but I’ve gone both routes in my career. That is, when I was trying to be more theory-minded I would start with a more general abstraction and then try to focus downward through the funnel, so to speak. When working at the theoretical level it’s easy to hang out there a bit too much and become what Spolsky dubbed an architecture astronaut.

      So after trying to avoid that, I ended up swinging too far in the other direction where I’d start with the architecture dead-ends, like you mention. Right now, I try to be more pragmatic where I can generally sense where an interface would go, where DI works best (which, honestly, I find in almost every case), when something needs to be architected for testability, etc. (I know, the testability should be first, but sometimes deadlines.)

      With growing skills and experience, your perception of what constitutes a challenge will slowly drift more and more into the abstract. You’re not satisfied with having stuff work, you want to know that it will work now and in the future, and you want to know that you’ve considered all of the relevant approaches and found the best one. And in addition to that, you want to know that you’ve solved the right problem in the first place, as I’m sure everyone can tell stories of building a brilliant solution to the wrong problem.

      I agree with this and it’s a really well-articulated point because often-times, when programmers talk about things like this regarding theory they’ll talk about efficient use of memory, space, and clock cycles. It’s not that those aren’t important, but I tend to look at it in the big picture. Is the ultimate result of what I’m doing taking a JSON string and serializing it to a database? Sure, I can make sure the software, classes, etc. are well-organized, but if I’m using a for look rather than working with pointers to hop through an array, does it really matter at that level?

      I think, when working with the web and the modern desktop/laptop, we are completely spoiled with resources to the point where we can certainly abuse them, but I think the consciouses programmer knows how to handle pragmatism at a level where you’re not over-optimizing or being sloppy (I hope, at least).

      The other thing is that the more programming you do, the more you realize that there are very few unique problems (especially in our field). The constraints in which our solutions exist differ so the implementation varies, but the problem isn’t one that has been unsolved.

      In the end, it is not very difficult to get the computer to do some specific steps. What is difficult is knowing what will be the eventual implications and consequences of the changes you’ve made if you multiply them by the different installations that are out there and project them into the future.

      Amen. And this is especially what’s important to know and to recognize when you’re working with a client or clients and you hope to have a relationship with them for years to come. I know there have been times where I’ve built something in the past that has been great and a pleasure to work with in the future as new requests come in.

      But I have plenty of stories that are not necessary the case, either. All I can do is wrestle with that code and try to be better about improving it.

      You’ve listed some of the current “bigger” problems in WordPress development, and for each of these, the time dimension also plays an important part. That’s what makes it so difficult and time-consuming for a large project like WordPress to make larger changes.

      Though I care about WordPress at it’s larger scale, I’ve resigned myself to thinking about WordPress in the context of my work, if that makes sense. For example, Rails is super opinionated (and I love that), so I simply took whatever came down the pipeline (no pun intended regarding their asset pipeline ;) and just used it. It’s the nature of the environment. When it comes to WordPress, I’m beginning to adopt the same mentality.

      The thing is, I don’t worry too much about things that others “hate” or “love.” If it works for me, I’ll use it. If not, I’ll write a simple utility to remove it for a given project. I don’t want to waste emotional energy on something when I can apply actual work to resolve it for a use case. I understand my situation is not the same for everyone but that’s where I am.

      In terms of things like, say, package management, for example, that’s a tough one to crack at the WordPress-level. But at the plugin-level, it’s not so bad if you have the proper precautions in place. If ever plugin started using it then that’ll be a hurdle we’ll combat at that time (unless it’s something people wanted to tackle before it becomes a mess, speaking of thinking through problems :).

      In all of this, computational theory can be a big help. It is sometimes very difficult to reason about the practical limits of a given algorithm. But most of the time, you can quickly find the theoretical limits… If you have a theoretical certainty that something does not work, you can immediately skip the practical tests.

      The theoretical limits, for me, take me all the way back to theory classes, projects, work, and even things I’d apply in my 9-to-5 and then the work I’m doing now. It was fascinating stuff and it’s relevant, but there are also different constraints in “the real world” so I find that you have to balance the theory and the application. Generally speaking, if I have a theoretical idea that might work I’ll usually try to do a quick script to test it or a quick program to see. If it yields something that might work, I’ll pursue it futher; otherwise, I just duck out and get into something I know will work.

      The theory also allows us to quickly find the edge cases, so that we can precisely test these, without wasting time doing tests that cannot provide conclusive results.

      Yes. Also “base cases” for example. I feel like that phrase is drilled into our heads from those who spend their time writing theory articles, books, lectures, etc. ;)

      And for most of what we’re developing, computational theory can already let us estimate how it will scale with volume, without having coded a single line. This is important when you’re trying to avoid building performance bottlenecks that you can’t get rid of later on.

      Right! It all comes back to implementation from there and that’s kind of funny but it goes to show how you don’t need to forgo one over the other if you can avoid it.

  2. Wow! I’m a WordPress implementer (per a test you provided a few months back, Tom). In college, I dabbled in philosophy and studied experimental design (experimental psychology). I admire the thinking and work of developers and so find this discussion fascinating and inspiring.

    Thank you both, Tom and Alain, for what you’re written. I can’t help but think it might be helpful for other developers to reflect on. May writing at this level benefit current developers and bring more well-prepared ones into WordPress.

    • I admire the thinking and work of developers and so find this discussion fascinating and inspiring.

      Thanks! I have a small interest in philosophy myself. I took a couple of classes in it during college (one of which centered around logic and then moving on to fallacies and then one that focused on writing from guys like Nietzsche, Kant, Kierkegaard, etc. Though I found the latter interesting, the former has lasted longer in my day-to-day stuff :).

      Thank you both, Tom and Alain, for what you’re written. I can’t help but think it might be helpful for other developers to reflect on. May writing at this level benefit current developers and bring more well-prepared ones into WordPress.

      Maybe I’ll think about writing more about this kind of stuff in the future. I know from conversations, other developers are also thinking about this stuff even if they aren’t writing much about it.

  3. I am an artist who looked into WordPress as a way to start a blog about my work. Simply put, it was a disaster.

    What I love about the creative process is that it allows adults to live in the abstract space for a period of time in a safe and acceptable way. Artists seem to need to obsessively assert our uniqueness to others, and I suspect it is because we all go into a kind of blank world when we create. Mine is like outer space itself only very peaceful. Maybe imagine always approaching a horizon in the desert that never moves. There are no rules there. No law. I can be messy and angry or sad or proud. I can be 5 or 500 years old.

    The idea of living a life only concerned with concrete reality literally makes me shudder. It would be a prison. Worse than prison. It would be torture. I have always believed that the reason people like art and movies and design and even cartoons is because if they free the artist from the weight of the world that translates. It does the same for the viewer.

    How does this relate to computer science or WordPress, for that matter? Well, first of all I am fascinated that computers are at their root a creation of mankind. Second, programming is the way we speak to our creation. How can so many people never even consider programming for its own sake? Why is everything a means to an end?

    I have this inability to learn by necessity. I can’t just learn the essential facts and move on. Either the knowledge remains completely disposable and I forget it the second its applied, or I commit and want to learn a big picture of whatever tiny slice of the pie I have sampled. Over the years this has been very polarizing and I think I realize that it is because it seems impractical. It seems better to be medium good at everything than to be super good at one thing and really bad at another to many people. I think that is connected to the whole issue of being so outcome-oriented, lacking ability to do anything that is not driven by need or obligation, and an all-around neglect of self that leaves people drained.

    Abstraction, or the absence of anything at all, is the last place someone like that wants to tread because when you are empty you have nothing to fill the space. It is sad and I wonder sometimes if people have always been like this or if it is a product of the times, and I figure that there has always been some weird quiet loner looking at the world and wondering that same thing. Probably could spot it in a group of baboons for that matter if you watched a group of them.

Leave a Reply