Code Simplicity

How Simple Do You Have To Be?

Sometimes, when you’re working on a project, there’s a question of, “How simple do we really have to be?” “How much do we have to simplify this thing?” “Is it simple enough?”

Well, of course, simplicity is relative. But even so, you can still be more or less simple. From the relative viewpoint of your user, your product can be hard to use, easy to use, or somewhere in between.

So, how simple do you have to be?

Honestly?

If you really want to succeed?

Stupid, Dumb Simple.

Apple knows this, one hundred percent. They make products that are so simple they’re practically idiotic. They aren’t the most technically advanced products (there are lots of phones that beat the pants off the iPhone in terms of features, for example), but they’re all usable by total morons. Big bright buttons, no clutter, straightforward interfaces, big text that explains everything–it’s like an elementary school textbook, but prettier and more expensive.

That’s the level of simplicity I’m talking about–the kind where you’d say, “Hey, my whole family could use this thing!”

But often, people really just don’t understand how stupid, dumb simple they have to be, to get to that level. For example:

When I’m at the mall, there are maps that tell me where everything is. On these maps, I want a huge red dot, with the words “YOU ARE HERE” in gigantic letters right there. Usually, though, I get a tiny red (or green, or yellow) dot (or triangle, or square) in the middle of the map that I really have to search for to see it. And then, off to the side there’s some text that explains, “The tiny green triangle means ‘You are here!’” Add this up to the general confusion of trying to find anything on these maps, and I could be spending five or six minutes just standing in front of this thing, trying to figure out how to get where I’m going.

To the guy that designed the map, this is all totally reasonable. He spent lots of time designing this map, so it was important enough to him that he would spend several minutes on it, learn all about it, figure it out, etc. But to me, the map is a very, very minor part of my existence. I just want it to be as simple as humanly possible, so that I can use it quickly and get on with my life!

Many programmers are particularly bad about this with their code. They assume that other programmers will spend a lot of time learning all about their code, because after all, it took a lot of time to write it! The code is that important to them, so isn’t it that important to everybody?

Now, the programmers I know are generally an intelligent bunch. There’s always a few exceptions, but mostly they’re very bright. But it’s still always a mistake to think, “Oh, other programmers will understand everything I’ve done here without any simplification or explanation of my code.” It’s not a matter of intelligence–it’s a matter of knowledge. That programmer who is new to your code doesn’t know anything about it. He has to learn! The easier you make it for him to learn, the faster he’s going to figure it out, and the easier it will be for him to use it.

There’s lots of ways to make your code easy to use–simple documentation, simple design, step-by-step tutorials, etc.

But, if your code isn’t stupid, dumb simple to use, people are going to have trouble with it. They’re going to use it wrongly, create bugs, and generally muck things up. And when all this happens, who are they going to come ask about it? Yes, you! You are going to be spending time answering all their questions…. (Mmmmmmm, sounds fun, doesn’t it?)

I know that none of us like being talked down to, or treated like we’re idiots. And sometimes that leads to creating things that are a little complicated, so that we feel like we aren’t “talking down to” to the user or the other programmer. We throw in some big words, make it a little less than simple, and people respect our intelligence but feel kind of stupid because they don’t get it. They might think we’re way smarter than they could ever be, and that is kind of flattering. But really, is that helping them?

On the other hand, when you make things stupidly simple, you’re allowing the user to understand your product. That makes them feel smart, lets them use the program, and doesn’t reflect badly on you at all. In fact, your users will probably admire you more if you make things simple than if you make them complex.

So when this question comes up of “How simple do we have to be,” you might as well ask yourself, “Do we want people to understand this and be happy, or do we want them to hate us and be frustrated?” And if you pick the former, then there’s only one level of simplicity that will assure your success:

Stupid, Dumb Simple.

-Max

5 Responses to How Simple Do You Have To Be?

  1. Show me an example of stupid, dumb simple code. (Compared to not so simple)

    • Max Kanat-Alexander says:

      Well, here’s a good example on short notice–a fictional main file for a calendar program:

      currentUser = User.log_in()
      currentUser.display_calendar()
      

      That would be opposed to a very long string of code accomplishing the same thing with few methods or functions. And of course, there would be various shades of gray in between. :-)

      -Max

  2. Yes, I find that splitting one line of code into n lines to be very favorable. Each middle step uses clearly named variables, unless the process is uber simple like a fibonacci function. When I was working on the Pinky web server, I could have just used four lines of code. But I figured that pulling out constants, converting them into variables, and giving informative names to them would help users configure the software. It’s better to waste a few bytes to newlines than spend hours of productivity exploring old and unfamiliar code.

    Pinky
    http://yellosoft.us/index.php?id=86

  3. Motyar says:

    Reading all the posts like a book.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>