Pragmatic development in WordPress is not a phrase or a term that I’ve found, read, or that exists (to my knowledge) outside this particular post. The idea has come from two sources:

  1. The Pragmatic Programmer by Dave Thomas and Andy Hunt,
  2. And a couple of projects that I’ve been working on recently.

I want to use the standard definition of “pragmatic” before I get into the rest of this post:

dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations.

With that said, I think there are a few things we can learn from this as it relates to applying pragmatic development in WordPress projects.

Of course, this raises the question of what type of situations calls for this?

Pragmatic Development in WordPress (When & How?)

I don’t know how the rest of you go about your projects, but I assume that many of you go a step further beyond “just getting something working.”

If you are at the stage of where that feels like enough, this isn’t an insult to you at all. Instead, it’s just meant to say that there’s always somewhere to improve. Even those of us who are using other programming techniques and tools have improvements to make.

Bottom line: Don’t read too much into that phrase.

That said, when I’m writing code I often leave notes around TODO AND FIXME so that I know to come back to these types of things and resolve them before actually shipping the final version of the product.

That is, I might be trying to get a deliverable to the client, and I know that the documentation for an area of code is complete, or I may need to refactor part of the code in the future, but that it satisfies a requirement for the current milestone.

Pragmatic Development in WordPress: TODOs and FIXMEs

A list of TODOs in a current project.

Plus, there are packages for IDEs and editors that help identify all the places we need to come back to these points. But that’s beyond the point of this article.

The simple point I’m getting at is this:

  1. Set aside a short milestone to go through and clean them up. After completing the first round of milestones and assuming that you’ve amassed a set of TODO and FIXME statements, set a milestone to fix them. Permitting your client is comfortable with that (which, in my case, I’ve never really had that problem), it should be okay. If they are skeptical, it should be easy to convince them of the benefits as to why it’s needed.
  2. Notes like TODO are okay given that they are just that: TODOs. Recognize that when you’re working on the code, and you need to drop a TODO or FIXME that it’s okay as long as you aren’t using it as an excuse just to ignore something you’re going to need to come back to do.

Here’s what I mean:

Getting a functional piece of software in front of our clients is arguably our number one priority. We need to make sure that we’re doing that. Whether or not our comments are completely fleshed out, or whether or not our methods or algorithms are not as optimized as possible during the initial development milestones is okay.

But that’s not to say that it’s not okay that it remains this way. And this is where pragmatic development comes into play:

You’ve got to know when the code is where you can ship it for the given milestone. The client can test it, it should work as expected, and then you can move to the next bit of work.

So the pragmatic development in WordPress projects comes into play when you’re moving through an issue or a milestone, and you’re checking off the requirements, but you have a level of intuition as to where something is good enough for now.

I’m not saying it’s good enough. I’m not saying it should stay that way. I am saying that you don’t need to place your own blockers in place to prevent completing the deliverable.

Instead, focus on the deliverable, leave notes to yourself in the code so that a tool or utility can show you what you need to revisit, and then return to them when the schedule permits.

More Pragmatism

There are plenty of other ways to employ pragmatic development in WordPress. This is just a high-level survey of one aspect of something you can do. Perhaps I’ll write more about this in future articles.

In the meantime, if you have ideas, feel free to share them in the comments. I’m all for hearing others’ experiences with something like this.