Don't Complicate the Solution
Designing software is about solving problems. Whether it’s a website, a desktop application, or a server tool, software is supposed to meet a need. We live in a world where many of those problems are extremely complicated. Too often I see people — very intelligent people — solving real-world problems with complicated, real-world solutions.
The definitions in their software must match real-life terminology, or their solutions must meet real-world expectations eye-to-eye. They spend days, sometimes months, toiling over their solutions, writing and rewriting code into a complicated mesh of logic and conditions.
And these solutions work. It’s not like they’re broken. They accomplish their goals, sometimes very successfully. But I can’t help but think that it just doesn’t have to be so hard.
Simplify the Problem
One of my favorite quotes is “Simplify the Problem, Don’t Complicate the Solution.” Before you attack a complicated, real-world problem with an equally complex solution, step back and see if you can’t figure out a way to make the problem simpler to start with. Simple problems make for simple solutions. Not always the most simple to develop, but the simplest to use. Complicated requirements almost always mean complicated software, both to develop and to use.
It’s Just Natural
When I think back to my days studying physics, I was always amazed that some of the most influential, ground-breaking physical discoveries were based off the most simple physical equations. Take Einstein’s e=mc2. Very simple equation, amazing implications. Nature simplified a very complicated problem down to something very simple. This repeats itself all the time: Newton’s second law of mechanics, the Maxwell equations, Lorentz’s equation, gravitation, and many more.
Redefine the Problem
Software gives you a marvelous opportunity to simplify real-world problems by just defining them to be simple. Take one of my favorite math jokes. (I know this makes me a geek, but it helps make my point. Give me a break.)
An engineer, a physicist, and a mathematician are shown a pasture with a herd of sheep, and told to put them inside the smallest possible amount of fence.
The engineer is first. He herds the sheep into a circle and then puts the fence around them, declaring, “A circle will use the least fence for a given area, so this is the best solution.”
The physicist is next. He creates a circular fence of infinite radius around the sheep, and then draws the fence tight around the herd, declaring, “This will give the smallest circular fence around the herd.”
The mathematician is last. After giving the problem a little thought, he puts a small fence around himself and then declares, “I define myself to be on the outside.”
Whether you understand the first two solutions doesn’t matter. You should, however, be able to see the beauty in the last. As this example is meant for humor, it’s obvious the simple solution here isn’t the most effective. But hopefully you get the point.
Wrapping Up
Make your solutions simple. If looking at your code, your interface, or your users reaction makes your head hurt, your solution is probably way more complicated than it needs to be. And sometimes you can’t simplify the solution by reworking the same problem. Sometimes you need to rethink the whole scenario, including the problem itself.
Post and Author Info.
Published November 14, 2007 by:
Commenting is currently off for this post.
So far there are 17 comments.
Another interesting thought is that e=mc2 doesn’t always hold true. It does in most cases, at least the cases that Einstein cared about (or knew about). But it breaks down under certain circumstances. That doesn’t make it less valuable. It is perfectly suited for the problem it is trying to solve.
One simple solution for the majority of cases and different solutions for the edge cases.