What’s Wrong With Computers

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.


  1. What? You blame entirely “bad programmers”, but fail to even mention the contribution of project management? Even the best of programmers, given certain real world constraints like insufficient time, may be working to satisfy their manager’s desire to patch up existing stuff like its an old leaky tire rather than take the added expense to fix things properly…

    Perhaps “good programming” is really what you meant by “good programmer”–it may or may not be the fault of the person who actually types out the code, there’s a lot of other people that go into the development process of complex software who may contribute just as much to the problems of the process 😉

    • Okay. It’s true that project management has an effect on programmers, and demands that they sometimes do things the wrong way. However, I tend to look at it on a larger scale:

      1) Who told the project manager than an impossible schedule could be met? (Now, granted, if the project manager didn’t even ask anybody whether or not the schedule could be met, that’s something that needs to be fixed.)

      2) Who caved in when project management demanded bad code to meet the impossible schedule?

      A whole program can’t go wrong just because of some last-minute hacks that have to be made in order to ship the product. You don’t get something like Windows ME because of last-minute hacks. You get something like that because of consistent, long-term bad design.

      So yes, project management definitely has its place in the hierarchy of responsibility. And I’m not saying bad management never ruined a project–in fact, it’s probably extremely common. But most of the bad software that I’ve had the chance to read the code of is just way too complex from the ground up.

      Even under pressure, sometimes a developer needs to step back and say, “Okay, pressure like this is going to happen in the future. How can I make things simpler now to avoid things like that in the future?”

      You’re right also that technically, I do mean bad programming. But I’ve encountered a ridiculous number of programmers (the vast majority I’ve known) who had no real concept of simplicity, and I tend to think that the vast majority of problems are caused by these programmers (since they comprise the majority of programmers I’ve met), not by good programmers under pressure who do bad.


  2. Okay. So I’m posting three years after the original post. Nevertheless, Max makes an excellent point.

    Let me begin by saying I used to be a programmer. Then I realized that programming was getting taken over by people whose greatest value was that they were always willing to cheaper than I would. I did not want to be a winner in some kind of “race-to-the-bottom,” so I moved on.

    Good programming is an art. While there are an infinite number of ways to write a program, there are NOT an infinite number of ways to write a simple program, or an “easy-to-maintain” program, or an “easy-to-understand” program.

    A lot of what makes programs simple is, 1) having some rational standards. Take for example variable names. Calling a variable “x” makes debugging a helluva lot harder than calling it “LOAN_PRINCIPAL” or something.

    2) Separating DATA and CODE. Can I tell you how many programs are out there where some variable is HARDCODED in the code? Too many.

    3) making code MODULAR. How hard is it to repair code when you have a 3000 (or 300000) lines of code to read. It’s easier (though not easy) if each “function” (say calculating a price) is set off in it’s own little module of 100 lines.

    4) not using global variables. Yeah. Enough said.

    5) having rudimentary error handling. Has anyone every found Microsofts “fatal exception has occurred at ZZ” even remotely helpful? No.

    6) Having even rudimentary documentation.

    7) Clear APIs. Write your modules with clear instructions about what they will do, what inputs they take, and what outputs they export.

    8) Basic input validation. If you are going to require input, and it has to be a number, make your program check that the input IS IN FACT A NUMBER.

    I could go on….but as I said….I have moved on from programming. Now I just write bad requirements….kidding…just kidding.

    – B.

    • Hey Ben. Wow, those are all such good points. Yes, those are exactly the sorts of things that I tend to start fixing as soon as I’m put on a system–the numerous strange complexities that people have added.

      I love your point about there not being an infinite number of ways to write a simple program, too, that’s so true. 🙂

      As far as programming being a market for the lowest bidder, I think that may be fading away as people come to see the ineffectiveness of hiring a large number of incompetent programmers. The modern trend of the most successful companies has been to hire a small number of extremely competent engineers, instead. (For example, the average size of an engineering team at Google is four people.)


  3. The implications are simultaneously depressing and liberating.
    I mean, just imagine how many bad programmers there are out there (percentage wise).
    And as if that was not enough on it’s own, they seem to conglomerate, bad programmers, using bad frameworks, making sure to keep good programmers away…
    And yes, management too, but not because of project management, but because they picked abd hired them in the first place.

  4. I am reading all your blog posts from the first one, and I must say my reading journey seems promising. You make good points which are true to this day. I support simplicity as much as I love programming.

    P.S- In absence of mentors, I glean information from such blogs, and however unsteady, I move only forward. Thank you for being a distant invisible guide.

Leave a Reply