标签: complexity

The term KISS is an acronym for "Keep It Simple, Stupid" and the punch line of a joke. But the principle is deadly serious. Albert Einstein is widely quoted as saying: "Make everything as simple as possible, but not simpler." or: "Everything should be made as simple as possible, but not simpler." or: "Simplify as much as possible, but no more." As you can see, his exact wording is uncertain—perhaps he said several versions of the same sentiment—but the meaning is crystal clear. Einstein firmly believed that the universe was both simple and understandable. Despite the awesome impact of his theories, the underlying assumptions behind them tended to be extremely simple: the speed of light is invariant, the energy of a photon has the value Planck gave it. Everything else Einstein did devolved from such inherently simple assumptions. When asked the secret to his success, legendary race car builder Harry Miller said: "Simplify and add lightness." (For the record, I've seen other people, notably the Wright brothers, credited with this quote. As nearly as I've been able to determine, the source really is Miller.) Another memorable quote is also attributed to Miller. When asked how he was able to develop such exquisite designs without any engineering training, Miller said: "When it looks right, it is right." Some of us would do well to remember this one, also. You would think that keeping things simple would be as natural for us as breathing. After all, simple concepts are easier to understand than complex ones. Simple solutions are easier to build than complex ones. We shouldn't have to be exhorted to keep things simple. Yet, I can't tell you how many times I've come across systems, analyzes, or approaches loaded with what I call " gratuitous complexity ." 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.