Complex problems, simple solutions

“For Every Complex Problem, There Is an Answer That Is Clear, Simple, and Wrong.” – H.L. Mencken

Hate to say it, as he’s a pretty controversial character in history, but he’s right about this one.  Is there anything worse than someone who waltzes into a problem (typically a middle manager) and starts out by saying:

“Why can’t we just…”? 

Nothing will bring out my inner Walter Sobchak like feigned involvement in a project.

Anyway, back to our story. 

I’m sure most readers will be familiar with the tired K.I.S.S. method.  Keeping It Simple, Stupid is a great mantra but you can only simplify so much before you give away key functionality.  Example: A user doesn’t know or care that your button requires 4 states, all of them requiring front and back end feedback to your app.  Rest, hover, mouse down and mouse up.  You have to capture all of those for individual actions on a page.  All they know (and need to know) is that they can click the button and cool stuff happens.  If you simplify it too much you get a stagnant, boring button that looks like a government website from 1998.  This is why Bootstrap is so useful

The key piece is (as I keep harping on) communication.  My clients usually don’t care about the technologies I use, unless they hire me for a specific skill set.  What they do care about is solving a complex problem for them without them having to become an expert in either the problem or the solution.  I pride myself on being a good listener.  I let them talk (and complain).  Most enterprise software is bad.  It’s true.  It’s like trying to feed an army…You’re gonna get hot dogs and beans.  Everybody gets fed but nobody looks forward to feeding time.  But I digress (WAIT, REALLY?). 

I’m a big believer in point solutions.  In fact, I started my company based on the idea that you could build incredibly useful tools on top of not so incredibly useful ones.  Given the advent of RESTful API’s, you can do some pretty amazing stuff that the creators never would have though of.  The classic examples are things like using the Google Maps and SpotCrime APIs to show heat maps of crime in certain neighborhoods.  Simple but amazing.  Most of the heavy lifting is already done for you.

A common challenge with developers (especially us seasoned, cranky ones) is that we tend to be untrusting with most technologies that are outside our comfort zone.  This is where they (we?) can sometimes make problems for ourselves by adding TOO MANY failsafes or saying stuff like “Ah, nevermind, I’ll just write my own parser”.  Famous last words.  The intellectual exercise takes over the project and you forgot what problem you were hired to solve.  Just use the built-in parser and spend your time testing with customer data, dummy.  Unless, of course it was written by a seasoned, cranky programmer (like all the good software).

About the Author: