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.