When it comes to talking about program architecture and terms like that, it always sounds a little bit like we’re taking something a little bit more seriously than it deserves.
This is a bit of a digression of my personal opinion, but I thought it worth sharing before getting into the actual post. Skip to the next heading if you feel so inclined.
When I think of architecture, I think of buildings and vehicles and various other things that, you know, keep humans use to live, to move, to stay alive, and so on. When someone says “architecture,” computer programs are not something that comes to mind.
Secondly, in the last decade or say, there has been this cultural shift in the programming community where compiled languages are “real” programs and anything that’s interpreted or that runs on some type of virtual machine is a script or isn’t a “real” program.
But as far as “architecture” is concerned:
the complex or carefully designed structure of something.
And as far as a “program” is concerned:
provide (a computer or other machine) with coded instructions for the automatic performance of a particular task.
So talking about program architecture isn’t inaccurate at all. It can feel a little weird, I guess, and I don’t know why, but that’s my digression.
But let me bring all of this rambling back around to WordPress.
On Matters of Program Architecture
This may be becoming a bit of a cliché, but some say that WordPress has a low barrier to entry so it’s a great place to start if you’re wanting to learn to write code.
I don’t agree with that. At all. But that’s not the point of this post.
I believe this mindset, though, can breed an unintentional habit and that’s one of creating a plugin or similar solution that will run on top of WordPress and have it start immediately within the confines of an IDE.
For some very small, very particular solutions, this is fine. But if you’re building something that’s likely going to be used by a lot of people or that fits a business need of even a small business with numerous customers, this is dangerous.
I believe that a program should start on paper. (That actually sounds like a quote that would appear on a meme, but whatever.) By that, I mean the program architecture should start on paper.
This entails that you or you and your team sit down with a notebook, a whiteboard, or one of those huge iPad Pros (don’t even act like you wouldn’t do it) and start drawing out all of the pieces of the program and what each part will be responsible for doing.
When you do this, you are undoubtedly doing to find things you didn’t think about prior to doing it. Think of it this way:
When you jump right into writing code, how many times do you find yourself thinking “Oh yeah, I didn’t think of that.” Or “Man, now I have to move all of this around because I didn’t plan on this use case.” Or something similar.
You know what I’m talking about because you’ve experienced it and if you haven’t experienced it, then it’s a matter of time until you land a project that will require a more serious program architecture than some off-the-cuff code that you’re able to pass off as a solid program.
The litmus test for a well-designed program is not “does this work?”
Software Development in WordPress
For those of you who are working in WordPress and who are looking to make a serious career out of software development with WordPress as your chosen platform, then consider planning your work out on paper first.
It really will make a lot of difference in how you plan our the work you’re going to do. And yes, you’re still going to make mistakes and hit points of frustration. They’ll be of a different type, though.
My guess is that making changes and scaling your program will be easier, though.