3 Tips to Stop Over-engineering Solutions

As a technologist, I think that is important to have checks and balances to avoid over-engineering solutions.  It’s easy to fall into the trap of overthinking a solution.  Every technologist does it at least once in their career.  Ok, probably more than once.  The reason this happens, in my opinion, is that we get excited over solving the problem.  We marry that excitement with the tools and techniques that we’ve been amassing in our toolbox. From there we end up with the greatest solution ever made, for the moment, at least in our minds.  We go on believing that until the someone, usually the client, says, “Its too complicated”.  

 

To get back on track, you have to assess the damage, so to speak.  I look at three questions:

It sounds simple but it happens more than you think.  I see cases where testing scripts and complex monitoring systems were setup only to find that effectively something had not been turned on.  If nothing else it is are reminder to start with the basics.

Looking at what you started with, did it get you from point A to point B?  What were the missing pieces?  Did your solution fill those holes?  Notice there nothing here about how. The “how” can sometimes cause one to get carried away.  If a form that is basic in nature, (think white background, black text and the text boxes) provided all the required information, then the fancy new form with colors, pictures and conditional entry better do the same thing.

This is where really the technologist has to be very careful.  We can’t help ourselves.  We want to use the new “shiny toy” that is the latest technology craze.  We have to fully understand the requirements and how that tool/technique/framework/process fits (or doesn’t fit).  Above all, we have to be willing to accept when the right solution is a small enhancement to what may already in place.

 

So, how to avoid overthinking a solution?

You’ve spent time gathering and documenting requirements, organize them into a requirements matrix or checklist.  As you complete each one, check it off the list.  When they are done, you are done.  If you’ve been working for awhile, completing tasks/features and have nothing to check off the requirements, odds are you’re over-engineering.

If you follow an agile methodology, you probably have some type of checkpoint at the end of each sprint.  If you’re thinking to yourself ‘agile what?’ then just group the requirements into groups with 3-5 tasks/features in each and schedule reviews at the completion of each group.  These reviews should be short, just long enough to review the feature(s), do they get you from point A to point B?  And more importantly does the client agree that it gets them from Point A to Point B?

There is nothing more humbling than creating a user guide for new features/functions/processes.  If you find yourself having to write a mini-novel, the solution is probably overthought.  I like to write mine as I am building the solution.  I find it helps with cross-checking requirements and reviewing with clients how things will work.  The bonus is when the feature is done and signed off by the client, the documentation is done too.  For complex coding solutions there are tools for building technical documentation, that’s different than this.   I’m referring to the diagrams and quick reference type guides that visitors to a website, volunteer helpers at an event or office administrators might use.  

Recently, I was creating processes for events my team were hired.  At these events, we were providing guest management (registration and check-out) and auction tracking (bidding and donations).  A few variables were different from past events such as software enhancements and program schedule of events for the evening, as well as other last minute changes a few days before the event, which is pretty typical.  I’d been pondering over how best to handle them.  I drafted up what I thought was the best solution only to have my team say, ‘uh, no’.  Well, that’s not exactly what they said, but the sentiment was that I’d made it more complex than it needed to be.  If you have a good team (and I do) they will give you the feedback that you need. If you don’t have a team, maybe buy a friend or family member a coffee to let you explain to them the problem or challenge and your solution.  If they don’t get it or ask lots of questions, that may be a sign that the solution needs to be simpler.

What techniques do you use to avoid falling into the overthinking wormhole?