Pragmatism in WordPress: On Agility

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.

8 Replies to “Pragmatism in WordPress: On Agility”

  1. Good advice. I often find myself looking back at code I wrote that made perfect sense to be months ago – and after working on other projects and coming back to it – now is difficult for me to understand. Making code readable is as much for yourself as it is for other people.

    1. Agreed – and I still contend that as readable as we try to make code, it’s still going to be code. That’s why I tend to be pretty comment heavy. It’s not just for others, but for myself, too :).

  2. Readability of code equals maintainability of code. If it scans well, it reads well, it is understandable, it is maintainable. And there’s no greater boon to a programmer than finding or creating well laid out, well organised code.

    Part of that is about your programming strategy. With regard to WP, when I first started I usually threw code into functions.php and directly edited templates to call my function code. Then as I got comfortable I learned to use the template override system, put my custom code in a functions plugin specific to that site, and most important of all learned to use the hook system. That way I had nicely discrete code blocks that were understandable precisely because they were in tune with, and leveraging how, WP itself works.

    That technique also makes it easier to use other people’s code. Like Woocommerce, a plugin (an app, really) that is brimming with juicy hooks, and templates just ripe for overriding.

    1. And there’s no greater boon to a programmer than finding or creating well laid out, well organised code.

      This is true, though I do think that there are times where some new strategies and/or patterns can be it a little more confusing.

      Case in point: Dependency injection is quite popular right now (and I’m a fan of it), but it’s harder to trace the code using that method than not, but it also comes with the advantage of de-coupling the code, you know?

      Part of that is about your programming strategy. With regard to WP, when I first started I usually threw code into functions.php and directly edited templates to call my function code.

      Most of us probably started that way :).

      That technique also makes it easier to use other people’s code. Like Woocommerce, a plugin (an app, really) that is brimming with juicy hooks, and templates just ripe for overriding.

      Yep – understanding the pattern and then properly using it makes all the difference when writing really maintainable, WP-specific code.

  3. I think a lot of the original thinkers behind the agile movement have taken up the banner of software craftsmanship because the whole agile movement has become too rigid(ironically!). By that I mean if you are not doing such and such a thing, or writing your software in a particular way you are not being ‘agile’, which is what Dave Thomas is referring to in his article I believe. I totally agree that we should code with agility which is why I wrote a series on what I think agile means. I prefer to subscribe to the software craftsmanship ideals as I think this is less prescriptive. I like to think of myself as a Codesmith as to me this implies a level of craftsmanship and quality without meaning I should stick to a small subset of practices.

    1. By that I mean if you are not doing such and such a thing, or writing your software in a particular way you are not being ‘agile’, which is what Dave Thomas is referring to in his article I believe.

      Yeah – and the guy should actually know given his involvement with the movement way-back-when :). I think it’s funny that it’s always been intended for how we development. That is, with agility, but how it’s morphed into something you are or are not – that being agile.

      I prefer to subscribe to the software craftsmanship ideals as I think this is less prescriptive.

      Yeah, I really like a lot of what Bob Martin started and then continued to push over the years (and how much traction it’s gained). I love the material they print – just wish I had more time to read more of their books.

  4. Great article, I appreciate the read. I know that one of the most important things for me when I first started coding WordPress was to keep things clear. I’m not the best coder in the world, but I do like that I can look back at my projects months later and not have to worry about not understanding what I wrote. I really love the idea of future proofing too.

    1. I’m not the best coder in the world, but I do like that I can look back at my projects months later and not have to worry about not understanding what I wrote.

      It’s a great feeling isn’t it? Being able just to actually look back at something you’ve written and be able to understand and maintain it?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.