Over the last few days, I’ve been building the site that’s going to power the membership aspects of the WordPress Development course I’m working on. Initially, I went into the project like any other developer: I was ready to sit down, start writing code, handle a bunch of configuration, and generally tweak my WordPress installation at a level that I was convinced would take me a long time.
But it wasn’t like that at all.
And that’s something I know developers are plagued with more often than they – or we – would like to admit:
We over-engineer our solutions all of the time.
It doesn’t have to be like that, though. It takes a slightly different approach and it requires that we fight our natural inclinations, but it can be done.
It just requires a more pragmatic approach.
Why You Over-Engineer Your Project
So what’s the reason that you – again, we – over-engineer our projects? It’s because we’re used to working at that level for our clients, right? Or maybe we’re used to doing it for ourselves.
We like to spend our time solving problems with code and we like to wrestle with problems until we’ve coded them into submission and committed them into the repository of a working state.
But that’s not the norm.
That’s what we do. Just like those who like to work on cars, tweak their guitars, or experiment with lighting and cameras do with their profession. Others just want to be able to drive, be able to strum, or be able to snap a moment in time.
When we spend more time writing code for our own projects that could easily be solved by off-the-shelf software from our peers, we’re over-engineering our project.
And when we’re trying to ship fast (and iterate), this is something that could be detrimental to the success of the project. I’m not saying it’s bad to reinvent the wheel (because it’s not), but if we have a deadline, we may end up missing it because we spent time trying to do something that’s already been done.
We tried to build something that we probably could have eventually done when existing software could solve the problem.
That’s not pragmatic. That’s not being a good developer. That’s being stubborn. Depending on the circumstances, it may border on arrogance. And I say all of this because I’ve been there. I used to be that guy (and I have to fight to not be that guy).
But at some point, we have to look at software this way: Nearly every thing we use is a dependency on something else. At least as far as the web is concerned.
How Do We Fix This?
When it comes to building projects like this, I think it helps to treat them as if we’re getting the specifications and/or requirements from any other client.
- What’s the problem that the project should solve?
- Is there anything that’s available that I can readily use?
- One customized components will I likely need to build myself?
- Are there any areas that need user testing?
- …and so on.
Yes, it takes some time to sit and write this down, but it takes less time to do that and approach it this way than it does to, say, wrestle with five payment gateways and their different APIs, doesn’t it?
Let someone who’s an expert in their domain focus on that, and we can focus on the domain in which we’re the expert. Then have we’ll have our software communicate with theirs.
That’s being a pragmatist. That’s not over-engineering our project.
What Did I End Up Doing?
Ultimately, I ended up being able to put together my project without having to write any code what-so-ever. Instead, I used all premium-level software:
from a developer’s pov, i *love* how easy it is to setup a site using:
— Tom McFarlin (@tommcfarlin) January 1, 2016
For those who are curious, here are the product page links to everything I used.
Once the site is live, up, and running, I’ll walk through all of the details on how I built the site. I’ll share why I made the decisions I did and if I’d reuse the software that I purchased to build it.
But for now, I’m going to work on being the most pragmatic I can be when it comes to projects like this. And maybe you can, too.
If you have more advice to add to this, I’m all ears. Drop it in the comments!