Don’t Over-Engineer Your Project

January 6, 2016

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.

The opposite of what it means to over-engineer your project.

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:

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!

Join the conversation! 12 Comments

I’ve run into this before. I’m one of a two man team, and some of the website design projects we get have to be done in a timely manner.

Since it’s just me, it’s hard to spend a lot of time customizing a theme or plugin function even though it provides certain benefits to the website. Sometimes we use premium plugins or themes to fill a need.

Going premium can harm that effort and spirit. Premium providers do not need help to corner the market.

Sure, premium code is good, it saves you time and keeps people in business but if you’re thinking “why reinvent the wheel?”, what spun up the WP wheel way back when? There were premium solutions at the time, so how did WP get born? You and I, we owe people. We owe all those open source contributors.

Paying for premium code pulls up the drawbridge on the community you leverage – you help make it seem as if good code cannot be free, that to do ‘real’ work, WP stars like you would not stoop as low as to mess with the open codebase. This is against the WP spirit.

Pay a developer to grow an existing open solution and contribute the solution back. Encourage others to do the same.

Which is completely fair and I’m a fan of when anyone offers other solutions, even when I don’t necessarily agree with them (just like you’re showing). I think it makes for good conversation :).

Going premium can harm that effort and spirit. Premium providers do not need help to corner the market.

In the context of GPL software, going premium doesn’t mean that you’re cornering the market. It generally just means that you’re providing support and/or automatic updates (or similar features) in a finite amount of time by putting the burden on the developers to manage it rather than the user.

GPL source code, by its license, is free so it’s not throwing up a wall and saying people can’t access it. This isn’t to say that some people don’t do this, but the code – at least for most of the products above – are available. But I choose to pay for them because I don’t want to have to spend my time tracking updates in various repositories and then applying them a year when I can get that for a few dollars.

On top of that, I’d love to see people continue to make their living by contributing to this economy and if I can do that by supporting them with dollars, then great. I’m happy to do so.

The majority of the software that I’ve listed above comes from people who both sell software for WordPress and who contribute openly to the economy. These people give back in numerous ways and to imply or assume it’s one or the other is inaccurate.

You and I, we owe people. We owe all those open source contributors.

What do we owe to people who volunteer their time? Gratitude, appreciation, and respect above all else. But a portion of these contributors are paid by their employer to contribute to the software. And those that’s don’t are either doing so out of a love of the project while also earning an income from somewhere else.

It’s not possible to contribute to open source software without making a living in some way. And if a person is able to make a living while doing that, then I think they should go for it.

Many of us – and I’d say even those who simply just discuss this type of stuff – are contributors in our own right. By committing code to WordPress, by offering free information via blog posts, by volunteering help in the support forums, by sharing free plugins and themes, by speaking at conferences, by offering advice, by helping a neighbor, by participating in forums, by answering emails, and so on and so on, we are giving back.

Even Matt who helped start WordPress started and leads a very successful company that has a business built around it. And some employees give back to the software that helps power the business, too.

Paying for premium code pulls up the drawbridge on the community you leverage – you help make it seem as if good code cannot be free, that to do ‘real’ work, WP stars like you would not stoop as low as to mess with the open codebase. This is against the WP spirit.

It doesn’t pull up the drawbridge especially when the code is already made available. The premium aspect of it helps developers to pour additional resources into the project as well as make a living off of it allowing them to pour more of their own time into the project or even spend some time contributing to other aspects of the economy they would otherwise be unable to do.

I definitely don’t mean to make it sound like good code cannot be free. That was never my intent and if I came off like that, then I did a poor job communicating and that’s on me.

I’m not a star, I don’t consider myself one, and I don’t see it as “stooping” to mess with the codebase. I’ve contributed code to WordPress. I don’t slam the codebase, either. If anything, I defend many of the actions and aspects of it that many people critique. But in this post and with what I’m trying to work on, we’re talking about an issue of pragmatism, not whether or not a person’s ego is in the way of messing with a codebase. Some people may feel that way, but I assure you that I am not one of those people.

Pay a developer to grow an existing open solution and contribute the solution back. Encourage others to do the same.

In some cases, I have contributed to the solutions I use. I dig GitHub for that exact reason.

And if an existing solution doesn’t exist? Then perhaps someone will create it and they’ll license it as GPL and then they’ll share the code and monetize it (or not) in a way that helps them to continue working on it faster than if they were not being paid for it.

Encourage others to do the same.

That’s a significant portion of what I write about every day: How to achieve things within WordPress so people can go and do without having to pay a lot of money to learn how to do so. I’ve spent time and money learning, now I’m turning around and sharing what I’ve learned in an attempt to help others.

There are several things in your comment that seem like there’s this dichotomy of either things should be free or they shouldn’t exist. But I think that’s a false dichotomy.

And to address the rest of the points you’ve mentioned:

That I don’t think people should mess with the WordPress codebase. I don’t think that at all. I think that’s part of what makes open source code great. But I also know there are inherent risks in doing so, especially if a person isn’t as well versed in building web software.

That there’s a single notion of what defines the “WP spirit.” There isn’t. There are some things, sure, that are true across the board, but if you ask a dozen people, you will get a variety of answers.

That I should contribute more to the community rather than paying people to do so. I already do contribute to the community and I also don’t mind paying other people for things I believe are worth my money. It’s possible to do both.

I appreciate your comment and though I don’t agree with much of it, I’m glad you took the time to share it because I think it brings up a number of points that are worth talking about.

I know others feel the same way you do; I know others don’t. And that’s great — above all else, I think it’s important to acknowledge that you can participate in both sides of open source software. That is, paying for aspects of it and contributing freely to it.

Just Getting Started with WordPress?

I write a lot about WordPress development but if you're just getting started, I recommend checking out WPBeginner. They have free training videos, glossary, and more.

WPSessions hosts some of the best WordPress training you’ll find anywhere from many well-known speakers.

If there’s something you’d like to learn, and it’s not already covered here, it’s probably been covered at WPSessions. If you use the special link below you can watch your first session for free and get a steep discount on the full-access VIP membership.