In The Mythical Man-Month, Fred Brooks distinguishes between aspects of programming that are hard because we don’t manage them well enough, versus aspects of programming that are inherently hard. This has stuck in my mind over the years as I’ve thought about how to improve my techniques.

Today I was thinking about one inherent problem, which is the level of specificity that programming requires. I don’t think most people understand this, so I wanted to take a shot at explaining it. To make this a little more concrete, let’s imagine that you’re designing software for a robot, which will help with your cooking.

You don’t like chopping vegetables, so you decide to program your robot to carry out that task. First, you program it to distinguish a vegetable from other objects in the kitchen. In this process, you realize how many different shapes vegetables come in, and how difficult it is to tell a vegetable apart from other objects. But eventually you limit yourself to 10 different vegetables and teach your robot to recognize them.

Next comes chopping. The basic up-and-down motion of the knife is easy enough to program, but there are a lot of decisions to be made during the chopping process. How large should the pieces be? What shape? This varies by the recipe and maybe by the vegetable, so you end up creating a chart that your robot can refer to when beginning a new chopping task.

You’ve spent more time on this than you expected, but now your robot is working pretty well. You set it to work on a bag of potatoes and turn your attention to other things. OOPS — when you look again, the robot has chopped a few rotten sections of potatoes along with the good sections. Your robot doesn’t know how to recognize bruises or spoiling, so you have to teach it that, too. Unfortunately, a rotten potato looks different than a rotten tomato, so you need more charts explaining all the possibilities. Eventually, by trying some different vegetables and watching the robot carefully, you get it to correctly identify and reject rotten vegetables every time, without throwing away too many good vegetables in the process.

Satisfied, you leave the room to work on something else, and come back in a few hours. OOPS — the bowl that the robot was using is full, and the chopped vegetables are overflowing onto the countertop and the floor. Now you need to teach the robot how to tell if the bowl is full, and what to do when that happens.

I think you see the problem now: software (whether in a website or a robot) only does what we tell it to do, and no more. The key is thinking, in advance, of every specific instruction we will need to provide, for every possible scenario. But this is difficult because our own minds are very adaptable and don’t require so much planning.

This is where my job as a programmer comes in. If a client asks me to build a robot that “chops vegetables,” I need to translate that to a robot that “identifies particular vegetables, divides them into particular sizes and shapes, rejects pieces that don’t meet particular standards, and stores them appropriately.” To the extent that I can think of these requirements in advance, I can offer an accurate time and budget estimate, and build a product that the client is happy with.

By the way, I have a narrower definition of “bug” than most people, and that’s easy to discuss using this analogy. When you found that your robot was not discarding the rotten vegetables, was that a bug? I would say no, because nobody had bothered to tell the robot about rottenness. That’s a problem, but it’s not the robot’s fault! If, on the other hand, you had programmed the robot to recognize a particular kind of rottenness in a particular vegetable, and it still failed to do so, then you’d have a bug — a piece of software that’s not doing a task it was specifically designed to do.

The good news is that once we get that robot working, it will chop a heck of a lot of vegetables without further intervention. The bad news is that it falls upon us to define in advance every detail of that task.