29   Keep It Simple

“Software is complex business. Any fool can write simple, elegant software. You’ll get fame and recognition (not to mention job security) by writing the most sophisticated, complex programs possible.”

Perhaps you come across an article that describes a design idea, expressing it as a pattern with a fancy name. When you put the magazine down, the chances are that the code in front of you suddenly looks as if it would benefit from the new idea—that pattern—you picked up. Ask yourself whether you really need that and how it will help with the specific problem on hand. Ask yourself whether specific problems forced you to use that solution. Don’t succumb to the pressure to overdesign and overcomplicate your code.

Andy once knew a fellow who was so fascinated by design patterns, he wanted to use all of them. At once. On one small, several-hundred-line piece of code. He managed to get about seventeen of the original GOF book Design Patterns: Elements of Reusable Object-Oriented Software [GHJV95] patterns involved in the hapless program before he was discovered.

That’s not how you write agile code.

The problem is that many developers tend to confuse effort with complexity. If you look at any given solution and say that it is simple and easy to understand, chances are you’ll make its designer unhappy. Many developers take pride in creating complexity: they often beam with pride if you say, “Wow, that is hard—it should’ve taken a lot of effort to arrive at!” On the contrary, you should be proud of creating a simple design that works well.

Simplicity is widely misunderstood (in programming as well as life in general). It doesn’t mean simplistic, amateurish, or insufficient in any way. Quite the opposite. Simplicity is often much more difficult to achieve than an overly complex, kludgey solution.

Simplicity, in coding or writing, is like a chef’s fine reduction sauce. You start with a lot of wine, stock, and spices and you carefully boil it down to a super-concentrated essence. That’s what good code should taste like—not a large watery mess but a rich, fine sauce.

Andy says:

What Is elegance?

Elegant code is immediately obvious in its utility and clarity. But the solution isn’t something you would have thought of easily. That is, elegance is easy to understand and recognize but much harder to create.

One of the best ways to measure the quality of design is to listen to your intuition. Intuition isn’t magic: it’s the culmination of your experience and skill. When you look at a design, listen to that voice in your head. If something bothers you, then it’s time to get an understanding of what’s wrong. A good design makes you feel comfortable.

Develop the simplest solution that works. Incorporate patterns, principles, and technology only if you have a compelling reason to use them.

What It Feels Like

It feels right when there isn’t any line of code you could remove and still deliver all the needed features. Code is easy to follow and correct.

Keeping Your Balance

• Code can almost always be refined even further, but at a certain point you won’t be getting any real benefit from continued improvements. Stop and move on before you hit that point.

• Keep the goal in mind: simple, readable code. Trying to force elegance is similar to premature optimization and just as damaging.

• Simple solutions must, of course, be adequate—compromising features for simplicity is merely simplistic.

• Terse is not simple; it’s merely uncommunicative.

• One person’s simplicity may be another person’s complexity.