In engineering, all problems are simple. You just have to know how to look at them.
Some folks seem to create complexity through lack of forethought, or by accident. A few seem to absolutely admire complexity and delight in creating it.
In my career, I've often been assigned to projects that were already ongoing. When projects were in trouble, I tended to be the "fast gun sheriff" they called in to clean up the town. As I looked at the problem and the proposed solution, I would find myself saying, in my most utterly untactful way:
"Well, it seems to me the problem is pretty simple."
The other people on the project tended to get highly incensed, and say:
"How can you say that? It's a very complex problem."
Continuing my penchant for tact, I'd say, "Seems pretty simple to me."
And they'd snort huffily, "Then you obviously don't understand the problem."
At this point, I'd usually shut up and accept their assessment. After all, I reasoned, they had been working on the project for months, sometimes years. Apparently they knew something I didn't; there were subtleties in the problem that I'd overlooked. So I'd keep my counsel and go on this assumption.
Then, after I'd been on the project for about six months to a year, I'd suddenly realize:
"Wait a minute! It was a simple problem! These guys just made it seem complicated."
It was along about that time that I formulated Crenshaw's First Law:
There exists a multitude of ways to take a simple problem and make it seem hard; Only a handful of ways to take a hard problem and make it seem simple.
Why do people sometimes over-complicate a problem and/or its solution? I can think of a few reasons, some of them nefarious.
Sometimes, it's because they don't really have the best interests of the customer or the company at heart. To give an obvious example, they may be on a cost-plus contract, and therefore have no incentive for simple solutions. Creating complex one earns them more money. If you're being paid by the hour, getting a simple solution, quickly, is not rewarded.
Sometimes, it's about personal advancement. If someone can convince his boss or his customer that the problem at hand is a complex one, he stands to get more kudos when he delivers a solution. If a group leader can convince his manager that he needs more people, he can later claim on his resume that he led more people.
I used to work for a NASA support contractor. We supplied engineers in support of various projects. I was to learn later that the NASA coordinators got their reviews and raises, based in part, on the basis of how many support people they were directing. Clearly, in this case, a coordinator stood to gain by convincing his management that his project needed more people working on it.
Sometimes it's a matter of ego. There are people--not a few of them in the computer and software industries--inordinately proud of their own intellects. For some, this is the driving motivation. Whatever they do, whatever they say, it's all about feeding their own overinflated egos.
To such people, simplicity is not a virtue. They seem to prefer--even actually seek out--clever/tricky solutions that will impress themselves and others with their superior intellects. In some people I've met, this goal dominates all others, causing them to risk failure or dismissal if need be.
But when it comes to simplicity vs. complexity, there's no need to invoke conspiracy theories and nefarious motives. Good old garden-variety ineptitude, even stupidity, will suffice.
In my experience, about 95% of all examples of gratuitous complexity simply reflect the fact that someone didn't think the problem through. Often, that's because they dove into implementing a solution before fully understanding the problem. Or because someone, perhaps the team leader, proposed a solution and the other team members accepted it without sufficient questioning and debate.
It's my firm belief that all problems are, at their deepest core, simple. And every problem, no matter how seemingly intractable, has a soft spot. Like a diamond to a diamond cutter, or a stone to a sculptor, there's a place where a carefully aimed blow will crack the problem wide open.
Sometimes that soft spot is anything but obvious. You're not going to find it by just whacking away at random. Like the diamond cutter, you have to study it; walk around it; view it from all angles; poke and prod it. Eventually, I believe that you will find the soft spot.
When I explained this approach to my professor and mentor, who supervised my dissertation project, he asked:
"What do you do if you can't find that soft spot?"
I could honestly answer:
"I don't know. It's never happened. I'll let you know if it does."
That was in 1966. Today, after more than 50 years of problem solving, it's still never happened.
Not once.
Jack Crenshaw is a systems engineer and the author of Math Toolkit for Real-Time Programming. He holds a PhD in physics from Auburn University. E-mail him at jcrens@earthlink.net. For more information about Jack click here