Dave Thomas, for those who aren’t familiar, is a notable programmer for both co-authoring The Pragmatic Programmer and for running the The Pragmatic Bookshelf company. In my opinion, he’s a fantastic person to follow if you’re into programming of any kind.

A few months ago, I stumbled across an article that he had written (that many of you have read) entitled Agile is Dead (Long Live Agility). It’s a great read for anyone who’s interested, and though I’m not particularly interested in talking about all of the things his article hits on, there are two specific things that I found relevant to anyone who is just getting started writing WordPress code, or who has been writing WordPress code for sometime and may need a refresher.

Pragmatism in WordPress

Our industry is plagued with a number of different models of software development. There’s behavioral-driven development, test-driven development, domain-driven design, waterfall model, spiral model, and on and on.

To be clear, I not knocking any of these. After all, none of these would have gained traction and taken a hold in the market had they not had obvious benefits.

Sometimes, though, I think that it can be intimidating for those who are getting into development to hear so many different ways and strategies for developing software, it can be a bit intimidating. I’ll go as far as to say that if you’ve been writing code for a while, it can even give you some feeling of guilt if you’re not on the up and up of what the latest trends are.

Find Yourself, Refactor, Repeat

But Dave reminds us that the core of software development – at least in an agile sense – can always be re-oriented around a single approach:

  • Find out where you are
  • Take a small step towards your goal
  • Adjust your understanding based on what you learned
  • Repeat

It’s a simple idea, isn’t it? Almost somewhat liberating especially when you think of how complicated code can get (and how fast the complication can come).

But that’s exactly it – the first step of finding out where you are can be extremely difficult. And sure, once you do that, it might be easier to begin working yourself to a specific goal, but for each proverbial turn in the code that you make, you have to start the process all over again.

At least, you do this until you’ve gained a clear understanding of the code and even potentially refactoring it along the way (the extraction method is not a bad approach once you have a proper understanding of the code, but I digress).

The point to take away from this specific process is that that if you’re just getting started in WordPress development, try to make this a habit now so that you don’t have to force the behavior in the future.

And if you have been programming in WordPress for a while, why not start this with your current project (or upcoming project)? It’s not really feasible to go back over the previous work that we’ve done and do this, but there’s no reason why we can’t start now, right?

Future Proof

Where we're going, we don't need code. Wait, what?

Where we’re going, we don’t need code. Wait, what?

The next point that Dave makes is a bit simpler:

When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier.

This can be interpreted and applied in a number of different ways, but one of the first things that comes to mind for me is how we actually write code.

That is, I think that as programmers become more acclimated to their environment and their skill level, they end up writing code that isn’t necessarily as clear. It’s clever. It’s concise. It’s efficient. It gets the job done. But it’s likely not readable.

Ideally, we should have clear, concise, efficient, and readable code but it’s easy to lose track of doing that when you get comfortable in a language or platform.

To that end, this is a good rule of thumb to remember whenever we’re working on our next project: Given a set options for how to tackle this problem, select the option that makes the future easier.

This may include writing slightly less clever code, or it may require a complete redesign of a particular set of classes. Whatever the case, make sure that your code is going to be readable and maintainable not just for now or next week or next month but for that year when the client contacts looking you for some changes for compatibility or to play nicely with a new theme, set of plugins, or a totally new application.

Just a Few Thoughts

Yes, there are a lot of things that can be affected by the above quotes, and the article from which the quotes have been taken is full of thoughtful (and thought-provoking) information so I still recommend reading it.

Anyway, the above two points struck a chord with me in the mentioned ways especially for those who are just getting started in WordPress, and even for those of us who have been building things using WordPress for sometime.