Unexpected side effects can be a serious pain in day-to-day life. They’re also one of the major issues in developing software.

t’s a problem of complexity. Computers are unfailingly methodical and logical; they do exactly what they are told. This makes them a fantastic crutch for the human mind, because they can handle enormously complex sets of instructions without missing a beat. The trouble is that it’s very easy to write code that will work fine on a computer but totally baffle a hapless human who is trying to read it.

If you end up with that sort of convoluted code, you can’t think about the whole picture at once, because all that information can’t possibly fit in your consciousness at the same time. You can’t confidently predict the effects of a change, because you don’t always remember all of the modules that depend on what you’re changing. Any defect or change makes you anxious. You  feel out of control and therefore frustrated.

Successful software developers prevent this by constantly managing complexity.

I see these side effect issues often in the rest of life too. In this information-obsessed era especially, we’re forever constructing situations too complex for us to wrap our minds around. (Think of all the times you’ve suddenly remembered that thing you were supposed to do that you forgot because you were doing all the other things you were supposed to do.)

I amuse myself by borrowing techniques from software development practice and applying them to life in general. Two that come to mind here are (1) eliminating duplication and (2) reducing dependencies.

Duplication is considered one of the cardinal evils of code. It might seem cruel and unusual to be so severe on our friends Copy and Paste, but the trouble with having the same thing in more than one place is that you have to remember to go to all of those places to change it. Forget to change it in one of those places, and you’ll be knocking your head against the door frame trying to figure out WHY THAT FILE IS STILL SAVING IN THE OLD PLACE!!!

We duplicate effort pretty often in day-to-day life, and (even more pernicious) we often have more than one place to go to for the same thing. I have a bad habit of writing to-do items on random scraps of paper that happen to be on hand when I think of the task. Very convenient at the time, but where do I go when I want to see all of the things I have to do? Gather up scraps of paper strewn about my house, office, and car?

On to dependencies. What I mean by “dependency” is a situation where one thing needs another thing to behave in a certain way in order to work—but it doesn’t clearly SHOW that it depends on that behaviour. It just assumes that the other component will always work that way.

Change the behaviour of the other component, and everything comes crashing to the ground, or a $1,500,000,000 rocket explodes on lift-off, or something along those lines.

One way we get around this in software is with interfaces. An interface is a kind of contract; the “client” component says “I need things to work like THIS” and then other components can “implement” the interface, meaning that they agree to provide that kind of behaviour. Ideally, when doing these things they’ve agreed to do, they do NOTHING ELSE. No side effects.

I find this concept to be helpful in life too. When I have a vague idea that I need something, it’s tempting to look around, find something that seems to fit the bill, and grab it. By taking the time to work out an “interface”—the sort of “contract” of what we expect and what we can provide—I figure we can prevent a whole lot of unexpected side effects.