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.
A computer is probably the most complex device that we can make in a factory today. It does billions of things a second. It has hundreds — if not thousands — of tiny parts that all must function correctly in order for it to work.
A program written on that computer is equally as complex. For example, when it was written, Microsoft Windows 2000 was the longest program ever created, at somewhere around 20 million lines. That’s something like writing a book of 150,000,000 words—nearly four times the size of the Encyclopedia Britannica.
The complexity of a program can be particularly confounding, because there isn’t anything to put your hands on. When it breaks, you can’t pick up something solid and look around inside it. It’s all abstract, and that can be really hard to deal with. In fact, the average computer program is so complex that probably no person could actually comprehend the entirety of how all the code works, all at once. The bigger they get, the more this is the case.
Thus, programming has to become the act of reducing complexity to simplicity. Otherwise, nobody could keep working on a program after it reached a certain level of complexity. The complex pieces have to be organized in some simple way so that a programmer can work on it without godlike mental abilities.
That is the art and talent involved in programming—reducing complexity to simplicity.
A “bad programmer” is just somebody who fails to reduce the complexity. Many times this happens because people believe that they are reducing the complexity of just writing in the programming language (which is definitely a complexity all in itself) by writing things that just “work,” without thinking about reducing the complexity for other programmers that they are working with.
It’s sort of like this:
Imagine you have an engineer, who, in need of something to pound a nail into the ground with, invents a device involving pulleys, strings, and a large magnet. Well, you’d probably think that was pretty silly.
Now imagine that I tell you: “I need some code that I can use in any program, anywhere, that will communicate between any computer and any other computer, using any medium imaginable.” That’s definitely harder to reduce to something simple. So, some programmers in that situation (and I might even say most programmers, but I don’t know all of them, so I can’t say) come up with something that involves strings and pulleys and a large magnet, that is only barely comprehensible to other people. They’re not irrational, and there’s nothing wrong with them. They were faced with a really difficult task, and they did what they could in the short time that they had. And what they made works, as far as they’re concerned. It does what it’s supposed to do. That’s what their boss wants, and that’s what their customers seem to want, as well.
But one way or another, they still failed to reduce the complexity to a simplicity. Then they passed this device off to another programmer, and that programmer also added to the complexity by using that device as part of his/her device. The more people who don’t reduce complexity, the more incomprehensible the program becomes.
As the program approaches infinite complexity, it is impossible to find all the problems with it. Jet planes cost millions or billions of dollars because they are close to this complex and were “de-bugged.” But software only costs about 50 or 100 bucks, usually, and is more complicated. There’s no way to spend time shaking all of the problems out of this infinitely complex device that’s being created.
So, a “good programmer” will do everything in his/her power to make what he writes as simple as possible to other programmers. A “good” programmer creates things that are easy to understand, so that it’s really easy to shake all the bugs out.
Now, sometimes this simplicity is misunderstood to mean that programs should not have a lot of code. Or that programs shouldn’t use advanced technologies. But that’s not true. Sometimes a lot of code actually leads to simplicity; it just means more writing and more reading, which is okay. You have to make sure that you have some short document explaining the big mass of code, but that’s all part of reducing complexity. Also, usually more advanced technologies lead to more simplicity, even though you have to learn about them first, which can be some trouble.
Some people believe that writing in a simple way takes more time than quickly writing something that “does the job.” Actually, it turns out that it’s faster to spend a little more time making things simple, as compared to writing things quickly at the beginning and then spending a lot of time trying to understand them later. That’s a pretty big simplification of the issue, but it turns out to be the case by programming-industry history. Many great programs have stagnated in their development over the years just because it took so long to add a feature to the complex beast that they had become.
And that is why computers break so often, because in most major programs out there, many of the programmers on the team failed to reduce the complexity of the part they were writing. Yes, it’s difficult. But that doesn’t make it okay to write complex software.