I think it’s worth reading the quick Twitter discussion, but I want to be clear that I mention Dave because the respect him as a developer, and he was being a bit facetious in his comments.
Bottom line, Twitter’s not the point of this post – it’s simply setting the stage.
I’ve written before about WordPress Craftsmanship which generally covers my thoughts on the entire process, but I don’t think I’ve ever mentioned my thoughts on software craftsmanship as a whole and why I think it matters in WordPress.
As such, I thought this may be a good opportunity to do so.
On Software Craftsmanship
Though I covered a bit of this in my WordPress Craftsmanship post, it’s worth re-iterating that a craftsman is defined as:
A person who is skilled in a particular craft or art.
And that I personally believe that all softwares craftsmen are developers, but not all developers are craftsmen.
Historically, the order of rank that people followed were as follows:
Now, Bob Martin has been one person who has been championing this in the software development industry for sometime, and seeing as how writing code for WordPress is a subset of that particular industry, I don’t know see why the labels can’t be adopted.
Don’t read me wrong: I don’t see us setting up guilds or anything to do this, but I do think that we could do a bit better than using a combination of copying and pasting code from a Google or Codex search to introduce developers into WordPress programming.
I think that this would go a long way into solving many of the problems that we have with theme and plugins conflict, but I digress on this point. For now.
Why Does This Matter?
The reason that I’m particularly interested in software craftsmanship is because I believe that building software should be treated as building anything else tangible in the real world.
After all, we’re working with a set of interconnected, moving parts all of which have to be able to communicate with one another, but also work in tandem and/or in sync with one another in order to ensure that the program works as expected despite a variety of external conditions.
The problem is that we’ve gotten lazy.
Because software can afford the luxury of generating bug reports, and get away with “just working” regardless of how poorly constructed the code is, many developers take the path of least resistance in order to ship something.
When we do that, we end up sending ourselves not only to maintenance hell, but we make it difficult for the code to operate within the greater context of the WordPress application (let alone the WordPress economy), and we throw any type of engineer principles that have been developed for the past decades to the wind.
And for what? To ship something quickly.
But the way I see it, companies that ship well-respected hardware and or software take their time to fine tune their product that maintain for more complex issues than many of us ever face.
Yet, we consider it good enough to ship themes that don’t work in a number of browsers or that break compatibility with WordPress, or ship plugins that might work for some but break others (or break other plugins).
We can do better than this. And this is where craftsmanship comes in.
In terms of a practical application, I’m don’t have a particular approach but I know that we’re beginning to experiment with this a little bit at 8BIT with our newest intern.
Specifically, we’re going to be having him work on some development and we’re going to aim to treat this is as a true software apprentice process.
Sure, apprenticeships could be equated with internships, but there’s a problem with doing that: Our culture looks at interns as paper pushers, and I’d rather treat the people that I’m working with who genuinely want to level-up their development skills with a title that’s more descriptive of their role.
At any rate, I don’t think software craftsmanship can be completely disregarded. Sure, it’s easier to talk about, but it’s a challenge to follow through on, but that’s what I want to do.
So in the next few months, we’ll see how this goes.