Code Simplicity

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…)