Episode 055: What is Over-Engineering a Solution & How do you Stop It?

Aired: 05/16/2017
Special Guests Tonya Mork

Overengineering or over-engineering a solution is something that every developer hates to admit that they do on a regular basis. However, to be fair its always hard to hit that “perfectly engineered” mark every time, on the first try. Usually something is under-engineered if you are trying to meet a deadline, or get a solution out, and over-engineered from the get go when its your own pet project. It is just so hard to hit that perfect mark, but today we talk about over-engineering.

Admit To Over-Engineering

The best way to keep yourself from constantly over-engineering is just to admit that you do it in the first place. Easier said then done, but its true, if you step back from your code once in a while and just admit “I over-engineered the crap out of this” you’ll be better off and can scale that code back down. Josh gave a great example where his code was so complex in order to do something very basic in the long run, it became a nuisance. I’ve done this a few times myself, especially when a client adds a piece of functionality in which makes total sense, but it was not engineered for it. While sometimes a quick fix, its still a quick fix that might have been implemented even quicker if it wasn’t for some crazy over-engineering.

Action All The Things?

WordPress has awesome Actions & Filters, and while I love to put in as many “do_x” as possible, sometimes it becomes a nuisance of over-engineering when you just have too many. For example if you have a parent theme which has a function that has an action, and you have plugin(s) that add into that action, and child themes which add into that action.. it can be a mess. Especially if you start factoring in a child theme which may remove an action, set by a plugin, or visa versa.

Actions & Filters are a great, but also a great way to start over-engineering something. With these you really have to think “will someone need to add into this? ever?” If the only use-case is a big “maybe” then maybe wait till that maybe is a real use case, then add it in. Yes, I know that is not “future proofing code” or whatever, but there is a line between future proofing, and over-engineering, and sometimes adding actions everywhere is just bad over-engineering a solution.

All the Layers!

As Tonya said, over-engineering isn’t always about adding new features, but just adding layers to existing functionality which you don’t really need. Stop doing that.

Over-Engineering a over-engineered solution

One thought on “Episode 055: What is Over-Engineering a Solution & How do you Stop It?

  1. Great topic.

    It’s all relative tho’ isn’t it? That is, if you’re trying to throw together a proof of concept, that’s not the same as an MVP, which isn’t the same as what you might want to do for a more mature product. What’s over-engineered for a PoC might be a sloppy and lazy for something more mature.

    Also, it’s relative to what’s being built, yes? Something one-off-y should have a different mindset and approach than something you might use over and over again – across multiple projects / clients.

    For better or worse Tonya’s more ROI driven approach might just be the way to go. Sure, sometimes that might feel dirty, but it’s a good metric to keep in mind as you lose sleep over optimizing some bit of code that might, over the longer term, end up on the editing floor anyway 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

  
Please enter an e-mail address