9 lies programmers tell themselves

Confidence in our power over machines also makes us guilty of hoping to bend reality to our code

Programmers have pride with good reason. No one else has the power to reach into a database and change reality. The more the world relies on computers to define how the world works, the more powerful coders become.

Alas, pride goeth before the fall. The power we share is very real, but it’s far from absolute and it’s often hollow. In fact, it may always be hollow because there is no perfect piece of code. Sometimes we cross our fingers and set limits because computers make mistakes. Computers too can be fallible, which we all know from too much firsthand experience.

Of course, many problems stem from assumptions we programmers make that simply aren’t correct. They’re usually sort of true some of the time, but that’s not the same as being true all of the time. As Mark Twain supposedly said, “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.”

Kevin Deldycke’s GitHub-hosted list of falsehoods that programmers believe is a good example of how disconnected cyberspace can be from reality. It’s a compendium that will only grow as others contribute their war stories. Consider it a good kick in the pants itemizing a thousand examples that say, in essence, “Remember, Caesar, thou art mortal.”

My favorite may be the list of falsehoods about phone numbers. If you think that saving a phone number for a person is as simple as putting seven or maybe 10 digits in a database, you’re mistaken. That works until it doesn’t because there are country codes, abandoned numbers, and more than a dozen gotchas that make it hard to do a good job keeping a list of phone numbers. Is it any wonder that there’s a smug smile of satisfaction on the faces of the Luddites who keep their phone lists in a little black book?

Here are a number of false beliefs that we programmers often pretend are quite true.

Questions have one answer

The database table is filled with columns, and each column has an entry or it doesn’t. It’s either full or null. What’s so hard about matching up an answer for every question?

Alas, sometimes there is more than one answer, then the table starts to fail. Maybe a person has more than one telephone number or a second weekend home. Database designers figured out some of the solutions to this by creating one-to-many and many-to-one mappings that can store multiple answers. Some of the more modern NoSQL solutions use a “document” model that lumps together all of the possible answers with different tags in one big soup.

+ ALSO ON NETWORK WORLD 9 classic hacking, phishing and social engineering lies +

These solutions are better, but even they have limits. Sometimes answers are valid only for a short window of time. A parking spot may be legal except during rush hour between 4 p.m. and 6 p.m.

If you think it’s enough to add one slot to the table to handle a window for each day, remember that sometimes there are several exceptions like 7 a.m. to 9 a.m. and 4 p.m. to 6 p.m. But don’t keep track of the time of day simply because the parking rules are often different on weekends, but then the definition of weekends changes. Parking is free in the District of Columbia on Sundays—but not Saturdays. Federal holidays are different too, and so are local ones.

Those are times only. The list of potential exceptions goes on and on making it impossible to imagine that a database will ever model reality by storing the absolute and final answer for any question no matter how simple.

1 2 Page 1
Page 1 of 2
SD-WAN buyers guide: Key questions to ask vendors (and yourself)