Software Animism

The tendency to attribute malice to inanimate objects is deeply entrenched in the human psyche. In a famous account from Ancient Greek times, a bronze statue caused the death of an angry demonstrator when it toppled onto him while he was whipping it with a flail. The statue was put on trial, found guilty of murder, and pitched into the sea in vengeance by the sons of the victim.

Nowadays, little has changed except that instead we throw mobile phones through windows or swear vengeance on recalcitrant applications. We should perhaps acknowledge this lingering tendency towards such primitive animism. I wonder occasionally if it wouldn’t boost morale of software development teams to introduce a similar sort of trial into their morning scrums? It might work as well as anything in fending off the ‘gremlins’ that seem occasionally to infest their code and stall progress.

I often hear developers speak of a piece of software “giving them grief”, or “deliberately making their life a misery”, as if it is possessed by some willful spirit. If the developers’ Slack channel at Redgate is anything to go by, MSBuild must be especially cursed in this way.

It is worse when the code is of their own creation. Rationally, of course, we realize that the program is behaving that way because we coded it incorrectly. However, as the programmer fights bug after bug, long into the night, ahead of a looming release deadline, the timing often makes it feel more like an organized attack.

Why didn’t these bugs appear in the relative calm of the start of the sprint? A psychologist would probably tell you that, subconsciously, programmers will only find the bugs that they want to find, when they want to find them. When systematic tests are forced on them by the pressure to ship a release, they are shocked suddenly by the apparent lack of control they appear to wield over their creation. Surely the software has started misbehaving entirely inexplicably, in ways that could not possibly have been a consequence of their own coding actions?

Can you explain why applications, or scripts, always seem to misbehave at the most awkward or embarrassing moment? Which are the worst offenders? As usual, our favourite response will win an Amazon gift card worth $50, and the winner will be announced in the next newsletter.


  • Rate
    [Total: 3    Average: 5/5]
  • David Howell

    Well it’s all based on induction in the sense of the electromagnetic, not logic of course!
    When you run a current through a conductor, it generates a magnetic field, and when you have lots of conducting circuits all lined up it increases the strength of the magnetic field. The converse is true as well, if you move a wire through a magnetic field (or move the magnetic field or oscillate it) a current is generated in the wire.
    The neurons and connectors in your brain transmit tiny amounts of electricity and that’s fine usually because they travel around in all directions and cancel out the magnetic fields.
    When you’re feeling angry and frustrated, on the other hand, they all line up, and if you are near the computer at the time then your magnetic field inadvertently generates errant currents in the circuits of your computer, leading to errors and unexpected behaviour.
    This explains why, when someone else like IT support for example, comes to look at your misbehaving computer it suddenly stops misbehaving, and you say “I swear it was doing that (bad thing) earlier!”
    So, as excruciatingly hard as it is, when working with computers you have to remain calm at all times and whatever you do, don’t make any sudden moves.

  • Jeff Moden

    “Recalcitrant” is the correct word but used in the wrong context, for it’s not the software to blame. It’s either the people that wrote the software, the people using the software, or more usually, a combination of both… and they all wait until the last minute to learn something new when it bites them.

  • A project manager I worked for long ago described software development as “the iterative removal of stupidity.” Deadlines ensure we cannot always do our best work; sometimes we have to deliver something that is less than immaculately conceived. Deliver in haste; re-code at leisure.

    In those moments when I want to send my can of Diet Coke crashing against the screen, I admit to a strong tendency to anthropomorphize the enemy — whether the Enemy is a devilish conspiracy of chips, wiring, and processing, or simple and mundane goofball logic. Maybe personifying the Enemy is a way of coping. “Why, I couldn’t have possibly been that stupid! It’s all *his* fault!” — “he”, being, of course, the expressionless screen and the patient keyboard. A fellow programmer, a woman, once asked me, “Why do you call the computer ‘he’?”

    “Because,” I replied, “women are not that perverse.”

    So then, if the problem is not demon possession of your database server, what sorts of things do cause these embarrassing bugs?

    Off the top of my head, some likely suspects…

    1. Parameter errors. I try to safeguard against these by validating every parameter before getting to the main logic in any of my procedures or functions. Try to leave as little to chance as possible. A NULL or blank input where you were expecting an employee id? Raise an error and then punch out. In your error message, explain as much as you’ll need to know later on to remind you of the site of this soon-to-be-removed stupidity.

    2. Data-type mismatches. How many times have you been forced to pull numeric data out of a character field and use them in calculations? Might want to check whether your field value contains alpha or special characters.

    3. Data truncation errors. Sometimes, particularly with the advent of VARCHAR (MAX), how much longer we’ll be forced to specify the lengths of character data? Life would be a lot simpler if you didn’t have to guess, well, gee, what’s the longest possible value for this field, and what will that be in two years? I tend to declare VARCHAR variable lengths that are multiples of what I reasonably expect the data to contain. Sometimes I’m even right.

    4. Duplicate rows. There is a defined primary key being stepped on by a duplicate key value in the results set. SQL Server hates that. Perhaps, somewhere in your logic, there is a JOIN of two tables where the one-to-one relationship you had assumed would always exist turned out to be a one-to-many. Your data is cheating on you. Or you misunderstood the relationship between two tables.

    5. Overuse of NOT logic. Debugging NOT logic, for me, is like thinking I was going fishing, but discovering that I was actually going untangling fishing lines. This might not bother a young and healthy mind — soft and pliable, like a wad of dough. When you’re old and crusty like me, however, your mind’s logical capabilities are baked hard and brittle, like a pretzel, and contorting it results in fragments and shards. Wasting precious neurons on untangling the NOTs is time wasted.

    6. There are times when it really is someone else’s fault. Notice that, at any movie house, they check your ticket before you step into the lobby. If you do get in without a ticket, from the theater’s perspective, that’s a data error, and it’s usually too expensive to chase down every single one of these. Now, what if they just let everyone in at first, but then go seat to seat, checking tickets and ushering those without a ticket out to the street? That makes life unnecessarily hard on the ushers and security guards and would tax the patience of those who want to see a movie. But that’s how some applications treat data: let it all in, and let the users perform the validation checking, if there is to be any at all. My personal thoughts are that every application workstation should have a compartment that, should the user enter in data that doesn’t belong, a little ball peen hammer comes out of it and whacks the user’s knuckles. I’ve never been able to sell that idea, but nevertheless it’s an idea whose time has come.

    But there is something comforting in the thought that all of our travails are someone else’s fault, and couldn’t possibly be due to our personal shortcomings — as if we had any! Hah! As the Good Book reminds us, the heart is the most deceitful of all things. And if there is one thing the heart is certain of, it’s certain of our own inherent blamelessness in all circumstances.

  • Peter Schott

    I’d say that it’s because users are ingenious when entering data or using the software in ways that no sane developer could foresee. I remember some users who abused one of our systems to run a food pantry. It worked, for a given value of “work”, but strangely enough when they encountered unexpected behavior, we weren’t about to try to fix it. They were using the software in a way completely unintended. We also had issues of scale where users would have orders of magnitude more data in their systems than we ever expected a user to have, let alone use in testing. When we ran into issues of scale, that would give us fits because reproducing it was awkward and often relied on their specific setup.

    Of course, there are times that it’s easy to see that a decision was poor – writing a framework and putting it into production before it’s tested, using the wrong datatypes or a non-normalized structure, or the like. Those are often forced on us by someone higher up. I know the framework issue resulted in much frustration until the architect vowed to wipe it out completely and worked unpaid OT for a couple of weeks to remove every instance of it in the code and replace it with EF. (It may have issues, but at least they’re known and not due to us trying to be clever.)

  • willliebago

    People in general quickly remember the exceptions. Most of the time when something works it is just normal and not worth remembering. The rest of the time when something doesn’t work is when it becomes memorable. A lot of people are really busy and that interruption just causes more bad memories 🙁

  • rogerthat

    This brings to mind an event over 10 years old that I still
    remember very clearly. During an early
    demo of a fairly large application, I cautioned my boss (who just had to drive
    the demo) not to click a specific button as I knew that action would result in
    causing the whole application to crash.
    I made him repeat what I said prior to the demo. Yes, you guessed it, in the first minute of
    the demo, he managed to click the specific button I had warned him about.

    I blame mental plasticity – developers tend to go down
    familiar paths while developing and testing an application. During a demo, interaction is expected and
    encouraged — members of the audience are quick to suggest performing an action
    in a different way other than the rote path the developer had been using, so
    the sequence of events is something entirely different…

    In today’s demo expectations, the end-user would actually
    drive, introducing even more extremes (placing a space before entering a
    number, entering spaces as “blanks”, adding hyphens to numbers, etc.)

    Two of the best preventative measures for “demo
    bugs” I’ve found are:
    1. Having QA as part of the development team – they have scripts they repeat,
    buy the solid QA professional also emulates many common user
    scenarios (like all the number tricks).
    2. As soon as possible within the iteration, make a QA build available to end-users
    and provide a means for them to log bugs.

    • Peter Schott

      Reminds me of a game I was testing recently. Alpha 01, the dev put notes in there to NOT test a specific branch because it wasn’t fleshed out. I’d say about 50% of us tested that branch first, reported bugs in it, etc. Apparently we’d all read it, absorbed it, and then something subconscious made us all remember that as the branch to try first instead. It was kind of amusing in retrospect and the lead dev was good-natured about it.

  • MarciaJ

    I’m pretty sure it’s the data gremlins that come in at night and attack the system.

  • Matt Gokey

    Same reason people think crime rates are getting worse when actually in all measurable ways they are improving. When nothing bad happens we don’t remember it, but when something does go wrong at a critical time, you remember it! And since it can happen, it will happen. We like to anthropomorphize things in general, so why not complex software? Then it’s not your fault because testing practices aren’t exhaustive. Altogether then it makes a lot of sense that some indignant software is intentionally sabotaging your demo day with the boss just before a 2 week vacation, doesn’t it!?

  • BillTalada

    You’re male and susceptible to periodic interruptions of lucidity by
    sexual thoughts.

    Descartes’ perfect demon has fooled you again.

    You live in the Americas and failed to sacrifice a Summer intern to the Incan
    Sun God Inti.

    Your boss undermined you just before your yearly review to avoid giving you a

    Several deterministic events can lead to indeterminate outcomes. See netlogo.

    You are depressed. I heard it’s very common among losers.

    You drank the punch and believe the patches of light on your monitor are
    actually controls you are clicking on.

    Just because you are paranoid, it doesn’t necessarily mean they AREN’T out to
    get you.

    Complexity arises from a few simple events. See three-body problem.
    No, this one is not about sex.

    You’re male and susceptible to periodic interruptions of lucidity by sexual

    Post hoc, ergo propter hoc. You believe you created a bug simply because
    there appears to be a bug now.

    Mercury is in retrograde. Hey, even astrology is right 0.5% of the time.

    You didn’t do it; it was like that when you got there.

    There are no bugs; there are only features.

    You’ve been cheating on Windows with a Mac.

    IT applied security patches after you tested.

    The NSA WIFI device hidden in your USB cable is interfering with your

    You didn’t exactly smash a probe into Mars but you did fail to be consistent
    with units of measure.

    The genetic algorithm routine you replaced last week is just now becoming

    Just like human viruses computer viruses are never completely eradicated.

    The bug is a real bug; how do you think bug got it’s name?

    You are gullible and believe demos are interactive instead of being video

    Be proud; at least your application works better than most paper towel
    dispensers, is faster than the DMV, and isn’t bloated with ads.

  • The answer is simple. You did not put it into production soon enough. If your customers do not have enough time to test your software for you then how are you ever going to find the bugs in a reasonable amount of time?!

  • Camilo Reyes

    TDD alleviates some of this, it’s an effective way to hold people accountable. When one developer writes code, leaves no tests behind, this makes it harder for the next person. Think if you observed a phenomena and weren’t able to test it? Would you attribute that to magical or random causes? Are the gods arbitrarily pissed off at you when it fails? Without testability, and examining results, there is no trace of intelligence nor design. It is impossible to verify what the original author was thinking.