Code Simplicity

Software developers throw around this word, “overengineering,” quite a bit. “That code was overengineered.” “This is an overengineered solution.” Strangely enough, though, it’s hard to find an actual definition for the word online! People are always giving examples of overengineered code, but rarely do they say what the word actually means.

The dictionary just defines it as a combination of “over” (meaning “too much”) and “engineer” (meaning “design and build”). So per the dictionary, it would mean that you designed or built too much.

Wait, designed or built too much? What’s “too much”? And isn’t design a good thing?

Well, yeah, most projects could use more design. They suffer from underengineering. But once in a while, somebody really gets into it and just designs too much. Basically, this is like when somebody builds an orbital laser to destroy an anthill. An orbital laser is really cool, but it (a) costs too much (b) takes too much time and (c) is a maintenance nightmare. I mean, somebody’s going to have to go up there and fix it when it breaks.

The tricky part is–how do you know when you’re overengineering? What’s the line between good design and too much design?

Well, my criteria is this: When your design actually makes things more complex instead of simplifying things, you’re overengineering. (Read More…)

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? (Read More…)

Sometimes, I think, people are worried that if they make their code too simple, then either:

• Somehow they’re not demonstrating how intelligent they are, or how valuable they are, to their managers, or
• The project will become so simple to work on that anybody can just steal their job!

It’s almost as though if they actually did their job right, then they’d lose it. Now, stated that way, that’s obviously a nonsensical viewpoint. But, if you’ve ever worried about it, here’s something to think about:

What if your code is so complex that you’ll never be able to leave your job? (Read More…)

A fast way to get complicated is to violate the purpose of what you’re doing.

For example, what’s the purpose of a web page? To give and receive information. Mostly to give information, and then some websites also take information, such as when you’re buying something.

How many complicated web pages have you seen that think they’re doing something else than giving or receiving information? Maybe they think they’re being entertaining, or something. I don’t know what their designers were thinking, but they probably weren’t thinking about giving or receiving information. Instead they’re hiding their information in a complicated mass of pictures and shapes.

Usually, the basic purpose of any given thing you’re working on is pretty simple. But if you add to that purpose, things can get complex pretty fast! For example, the basic purpose of Bugzilla is to store and organize bug reports. If we suddenly made Bugzilla also able to read your email, it would get ridiculously complicated. (Not that Bugzilla is the simplest program in the world, but we’re working on it.) Can you imagine what the UI would look like? Where would we put all the buttons? That would be a violation of Bugzilla’s purpose.

It’s also important to think about user’s purpose. (Read More…)

Defining “simple” really depends on your target audience. What is simple to me might not be simple to my mother, or my friends. Also, when I create something, it’s always relatively “simple” to me, because I understand it inside and out. But to somebody who’s never seen it before, it might be very complicated.

This is why in VCI I put a big, obvious section of documentation near the top called “New To VCI?” And then it contains some simple, obvious steps to take. It’s written as if the reader knows nothing about VCI, because if you’re new to something, you probably don’t know anything about it.

I see way too many software projects mess this up. You go to read the documentation, and you’re presented with a huge mass of links and no direction. This is simple to the long-time developer of the project, because a page with lots of links lets that developer quickly go to the part they’re looking for. But for the new person, it’s complicated. On the other hand, for the long-time developer, adding a page with big, simple buttons and eliminating that list of links would add to the complexity of his task, because he’s just trying to find a very specific thing very fast in the documentation.

The only thing worse than complex documentation is no documentation, where you’re just expected to figure it out for yourself or “already know.” To the developer, the way his program works is obvious, but to the new user, it’s totally unknown.

With software, there are all sorts of different viewpoints. Just a few would be: Programmer, QA Engineer, Manager, Support Technician, User, Power User–to all of these people, “simple” will be different.

Context has a lot to do with this too. (Read More…)

There is only a certain amount of the future you can know. You can know with some certainty that you’ll be breathing in the next few minutes. You can know with some certainty that if you go out to your car and push the gas pedal, the car will probably go somewhere.

The brighter somebody is, the better they can accurately predict the future.

However, no matter how smart somebody is or how much they know, there are some things about the future that you can not know.

In programming, the biggest thing you can’t know is how your program will change in the future. You can know that it will change–that’s guaranteed. But how it will change five, ten, or twenty years from now, we just don’t know.

A common mistake that developers make is designing too far into that unknown future, making too many assumptions about it. Everybody’s done it, probably. I’ve done it. You set up some huge, rigid framework and plan, and you get started setting it up, and either:

• It doesn’t work and you have to re-write it all, or
• Large parts of it never get finished, and then there are little useless pieces sitting around in the code that were “going to be used” but never were, or
• After years of work you find that you’ve designed yourself into a hole and have to re-write the whole thing.

I did that once, in Bugzilla, in a simple but stupid way. (Read More…)

Note: This is a “classic” article from my old blog, but with some new revisions. This article was where I started with the idea of simplicity in computing, and I’ve been going on that idea ever since.

Computers have created a major societal change. The reason is that you can do more work with fewer people. That’s really the entire value of a computer—it can do a lot of work, really fast. If a person was to do, by hand, all the math that a computer does just when it starts up, it would probably take the rest of that person’s life.

So that’s great.

Problem is, they break. They break all the time. If anything in my house broke as frequently as my computer, I would return it. Most of the people that I know, their computer crashes at least once a day. Almost every day, I see a computer break in a way that I’ve never seen before. That’s been pretty much every day since I was about eight years old, so I’ve probably seen a computer break over 41,000 different ways, now.

That’s not great.

Why do computers break so much? For software, there’s one reason, and one reason only. Bad programmers.

Now, I didn’t used to be a programmer, and so I wondered about this sort of thing. I suspected that there were bad programmers, but it was sort of like blaming “witches” for a bad crop harvest. I didn’t really know anything about the subject, so there was some reasonable doubt.

Now that I am a programmer, and I have worked for a long time in a professional setting, and have talked extensively to other people who have been professional programmers for a long time, I can confirm that it really is bad programmers.

So, what is a bad programmer and why would somebody be one? This term, “bad programmer,” is pretty ambiguous. Also, most of the people I’ve ever met aren’t totally illogical, so there must be some reason why they would do “bad” programming.

Basically, it all revolves around complexity. (Read More…)

Welcome to Code Simplicity!

There are a lot of technical blogs in the world. There are a lot of technical people in the world. It’s a technical world.

Unfortunately, it’s also becoming more and more a complex world.

The focus of Code Simplicity is to discuss simplicity and simple things in the world of computers. I think the greatest application of intelligence is taking something complex and making it simple.

If you know of any particular examples where somebody took something really complex and made it simple, let me know and I’d be happy to feature it here. I’d really like real-world stories of how simplicity improved your life in the world of computing.

At first, I’m going to be re-posting some (possibly revised) articles from my personal blog. After that, there should be some new content, and hopefully, some user-submitted content!

Anyhow, this is mostly just a “Hello, and Welcome” post, and soon there will be more real content here.

-Max