Practical WordPress Development

Software Craftsmanship and WordPress

Earlier this year, I shared a post on why software craftsmanship matters in WordPress development. It stemmed from a Twitter conversation that I had with Dave Donaldson at Max Foundry.

In the comments of that particular post, Dave also followed up with this comment:

Just to be clear, my issue with the term “software craftsman” is that it’s taken on an elitist connotation by many people, and that bothers me. It also bothers me that there is some correlation between people who spout “software craftsmanship” but don’t actually ship anything.

I try not to spin my wheels on topics that I’ve already discussed in-depth, but I recently stumbled across another post by Uncle Bob Martin – arguably the biggest proponent of the software craftsmanship movement – on the 8th Light blog that brought up the same concerns that Dave mention.

Specifically, it discussed the “elitist connotation [demonstrated] by many people.” Call me naive but I’ve simply been missing out on the drama that’s been going on surrounding this entire “software craftsman” thing.

For me, it’s always been about the manifesto, and the ability to make sure that I – as a developer – am doing the best job that I can to build good things for others and for myself.

It’s also a matter of making sure that I’m actively trying to learn from others as well as evangelizing my own practices to others not because I think that I’ve got it figured out, but simply to give back to the developer community.

But apparently, there’s more going on.

The Laborer and the Craftsman

To clarify, the post on the 8th Light blog is actually a rebuttal to a post by Ted Neward called The Dark Side of Software Craftsmanship.

In the article, Ted shares his thoughts against the whole “software craftsman” movement, and if you opt to read the entire article, you’ll notice that Ted has legitimate reasons to feel the way that he does. Similarly, Bob provides a solid rebuttal.

The purpose of this post isn’t to go back and forth on the drama – there’s no fun in that for me – but to provide an explanation as to how I view software craftsmanship and WordPress.

The Manifesto

Before actually talking about craftsmanship and WordPress, it’s worth noting that there is an actual manifesto for software craftsmanship:

Not only working software,
but also well-crafted software

Not only responding to change,
but also steadily adding value

Not only individuals and interactions,
but also a community of professionals

Not only customer collaboration,
but also productive partnerships

Simple, right? And it provides a clear definition of what software craftsmanship entails, and from that, we’re able to infer what it doesn’t entail.

To distill the manifesto into three points, it’s clear that we should:

  • Build well-architected software
  • Partner with one another, be it fellow developers and/or clients
  • Provide value through our work and education

Unfortunately, egos, opinions, and more aggressive conversations (for lack of a better term) get in the way of trying to better ourselves as professionals. But that’s a post for someone else to write.

I’m more concerned with what software craftsmanship looks like within the context of WordPress development.

Software Craftsmanship and WordPress

I’ve been asked a few times primarily via email or Twitter to share my thoughts on this topic, and this post has been one that’s been a long time coming, and that’s been somewhat of a task to write because I do believe that this is something that should be objective, but there’s clearly room for subjectivity.

So with that disclaimer, here’s how I view software craftsmanship and WordPress.

Well-Crafted Software

One of the biggest mistakes that I made early in my career is that I tried to treat software architecture like an algebra problem. I believed that I needed to “solve for X.”

That is, I believed that there was a single right way to build software and that prior to getting writing any code, I’d spend time diagramming out all of the relationship between the entities in the application.

The truth is, there’s no single right way to build something. There are ways that are better – or more optimal – than others, and we should strive to pursue those solutions.

The barrier of entry for WordPress development is relatively low, but I do believe that writing well-crafted WordPress software is a bit more difficult.

It’s easy to get something working, but it’s more of a challenge to build things the right way.

There are a number of factors contributing to this that I may discuss at another time, but suffice it to say that combining tried-and-true software development practices along with the WordPress coding standards and other factors of quality – such as design patterns, unit testing, etc., where applicable – will contribute to building well-crafted WordPress software.

Steadily Adding Value

Value is completely subjective based on where and how you interact with the software.

By that, I mean that a user will interpret value significantly different than those who design interfaces or write the code to bring the project to life, and the clients will interpret the value of the work differently than vendors.

The thing is, I think developers are uniquely positioned such that they have, at some point, fulfilled all roles: a user, a customer, and, of course, a developer.

1. The User

I believe that users will find their value based on how the product works. If it solves their problem, there’s one level of quality. But if it solves their problem, is easy to navigate, and is a true pleasure to use, then the value is increased even more.

2. The Customer

Customers will find value based on their interaction with the vendor and good of a job they do at providing value not only in the product being built, but in how they communicate and solve the problem at hand.

I’d say that poor quality is demonstrated by those developers who take project requirements, forgo understanding the problem domain, and do their best to turn around a project quickly without regard anything that may help truly streamline and improve the the customer’s workflow.

Perhaps a better way of stating this is to say the customers will find more value in vendors who demonstrate that they care deeply about understanding the problem domain, building an elegant solution that genuinely improves their current process, and that creates several deliverables that demonstrate progress and provide opportunities for shorter feedback loops.

3. The Developer

I think that developers steadily add value by constantly investing themselves and by giving back to the community.

First, I think that we should be reading articles and blogs and participating in conversations and code reviews and so on that allow us to better our own skills. In fact, I’ll go as far as to say that we should introduce one new technique or concept into each new project.

Secondly, I think that it’s important that we give back to the community. This can be in the form of sharing your opinions, thoughts, and code on your blog, making projects freely available, or contributing to some of the available projects.

But this also feeds into the next point.

A Community of Professionals

If there’s one thing true about WordPress, it’s that there’s a large community. And even though I think we need to do a better job of qualifying it, the truth is that there are a lot of people involved in a very different capacities all of whom are working to make the platform even better.

That said, this is where I think the potential for the greatest amount of drama exists because we all care so passionately about the platform and our work that sits on top of it, that we have opinions that are often wrapped up with emotion that greatly impact how we share our thoughts and how we converse with others.

And though we aim to be a community of professionals, I think that we often act like anything but.

But if this is a cornerstone of software craftsmanship, then it demands that we be open-minded about others’ opinions and propositions on whatever aspect of the platform or project on which you’re working and that we can respond respectfully.

That’s what we need to strive for, and that’s one area where those of us involved in WordPress need to improve.

Productive Partnerships

Finally, I think that productive partnerships are the professional inter-relationships that exist among users, customers, vendors, designers, and developers.

We should be learning from one another, providing constructive criticism on how to improve something, or offering solutions to better ourselves and our community.

So, in WordPress, this could be bloggers helping bloggers, designers helping designers, developers helping developers, and the various permutations and combinations that exist with, say, developers helping bloggers, and so on.

Additionally, I think there needs to be an extremely high level of respect among all parties involved in a project, such that we all leave a given project, conversation, or relationship with something greater than when we first arrived.

The Truth of The Matter

As much much as I believe that the software craftsmanship manifesto should be a set of objective principles, the truth of the matter is that  we’ll all bring our own unique perspectives to applying it in our field.

Obviously, that’s what I’ve done here.

To be brutally honest, I don’t consider myself an optimist and I don’t think the odds are looking good that the dark side of software craftsmanship displayed by the subculture of developers is going to decline.

If we can at least stop going back and forth with this elitism and focus more on doing good work, having productive conversation, and doing a better job of respecting one another, then maybe we can make some sort of progress not only in our day-to-day work, but in restoring the level of respect that software craftsmanship should have at least as far as WordPress is concerned.


  1. John Saddington

    i read the entire thing and i give it 2 opinionated-yet-professional thumbs up.

  2. Mike Schinkel

    I don’t think the odds are looking good that the dark side of software craftsmanship displayed by the subculture of developers is going to decline.


  3. Ben Harold

    Seeing the terms “WordPress” and “software craftsmanship” in the same sentence makes me LMAO. I just downloaded 3.5.1 to see if it was as bad as I remember. It’s worse. I remain convinced that WordPress was developed wholly by monkeys randomly hitting keys on a keyboard.

    • Mac

      LOL, monkeys are pretty smart. i wouldn’t be making fun of them because they might not be too generous in the way they react. And monkeys have a good memory and pass tips down from generation to generation, which I suppose is bad news for you.

  4. Doug Bradbury

    Thanks Tom for you very well thought out post. As one of the original authors of the manifesto, it encourages me to see someone digging so deeply into it’s values and applying them to a particular context.

    Well Done.


    • Tom McFarlin

      Thanks a lot, Doug. Definitely appreciate from hearing from one of the original authors :)!

      And yeah, it’s something I spend a lot of time thinking about and trying to apply. The drama around the movement is just a bit of noise that I think is unfortunately all too common on the web.

      Keep spreading the good word :).

  5. Edward McIntyre

    Great post.

    You touched on my biggest issue with the WordPress software & theme craftsmanship but in a slightly different context.

    One of the biggest mistakes that I made early in my career is that I tried to treat software architecture like an algebra problem. I believed that I needed to “solve for X.”

    Solving for X is unfortunately what I see with a lot of the WordPress ecosystem, but not in the context of a single right way to do something. In my opinion WordPress devs are great at solving their core problem, but many forget about the community and that others may need to solve for y and z. I see a culture of bare minimum where devs don’t provide logical hooks to extend their work, forcing you to fork it, change the core code and build your own version.

    This is also true of the design community. “Premium” themes are terrible for this these days. You will see designers solving for X and forgetting the rest. There are some amazing portfolio themes out there, but few take the time to solve for WordPress’s core function, blogging. Few think to build their CPT in a plugin so that the user has choice.

    Unfortunately, it all boils down to profit. We as a community build what we know will sell and often forget the craftsmanship, the small details that make all the difference in practice. In reality a quality product is a profitable one, simply from the aspect of support.

    When I think of craftsmanship in the context of music, imagine artists that went past what’s popular, creating layer after layer so that every time you listen you discover something new. Was is necessary to sell the product, probably not… but it’s what creates legacy. Something I think we should all strive for in software craftsmanship.

    (Note to self: should probably start blogging instead of writing a book in the comments lol)

    • Tom McFarlin

      Solving for X is unfortunately what I see with a lot of the WordPress ecosystem, but not in the context of a single right way to do something. In my opinion WordPress devs are great at solving their core problem, but many forget about the community and that others may need to solve for y and z.

      We may different a little bit here. As a developer, I’m a fan of the SOLID principles so I tend to think functions, classes, and overall products should do one thing and do it well.

      This is not to say that we shouldn’t consider edge cases for the problem that we’re solving, but I think a product’s identity lies in what it does do – the more that it does, the less identity it has.

      For example, I think of Microsoft Word – at least prior versions – as being extremely bloated because they just kept adding feature after feature after feature as requested by the enterprise.

      Why not make bundles of add-ons instead, then businesses who need certain packages could add them to core solution (specifically, a word processor)?

      Anyway, for the sake of deviating too far, I digress.

      As an aside, your point on music is spot on and exactly why I enjoy listening to music – especially older rock and roll – through a nice set of headphones. You just hear things that you otherwise wouldn’t.

      • Edward McIntyre

        The interesting thing is I believe we are saying the same thing. :) The ability to create “Add-ons” is exactly what I was talking about, but the ability to create them without modifying the source of a plugin requires it to be built with extensibility in mind.

        As for music i’m kinda old skool that way, I almost always listen with headphones and only purchase full albums. There is something about taking in an album in its entirety that changes perspective.

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑