Click here to monitor SSC

Simple-Talk columnist

Taming the spirit of the machine

Published 1 August 2013 12:58 pm

Often, a programmer will wrestle with code stubbornly; expending herculean effort to conquer a problem of relatively minor significance. This is OK. Sometimes, developing an application is like training a wild animal, when it defies you and refuses to work, you can’t turn your back on it. You have to show who is boss.

LionTaming

A long time ago, my mother insisted on keeping a bull terrier. Though generally amiable, it would attack anyone, when in the mood. In the spirit of self-preservation, I took lessons in animal training. Never show the slightest fear, never turn your back on an assailant, and react swiftly and decisively to any attack. Soon after taking these lessons, the bull terrier attacked me for the last time. In a flash, I’d knocked it off its feet, rolled it over, grasped its bottom jaw firmly and opened its mouth wide. This sudden immobilization subtly altered our relationship. Whereas the rest of humanity remained fair game, young Phil was permanently off the menu.

What I learned has proved useful throughout my career in IT, not for dealing with management, although I’ve always wanted to try out the above maneuver on an over-excited CIO, but for tackling awkward development tasks.

Sometimes development tasks are so complex that they become, to superstitious humanity, rather like a wild beast that needs taming. A programmer cannot allow a problem to get the upper hand. It feels like defeat to knock off work with that irritating bug still in place. You have to order up the pizza, look the problem in the eye, betray not a flicker of apprehension, and sort it out. The alternative is a distracted evening followed by a night spent dreaming of the problem, and then another day wrestling with an emboldened application, eager to return to its natural wild state.

In an information age, we can forgive programmers for anthropomorphizing inanimate programs. It’s a way of buoying confidence, ensuring quality, and keeping one’s skills honed. Besides, once tamed, I grow quite affectionate towards some of my applications bless ‘em. Perhaps I should start a new career as an Application-Whisperer.

11 Responses to “Taming the spirit of the machine”

  1. davidcaughill says:

    I love this idea! And don’t forget the massive amount you learn in those late-night, up-to-your-eyebrows-in-code marathons. Some of my best lessons have been learned there and the feeling of satisfaction when you conquer such a challenge is immense – well said!

  2. JonRobertson says:

    I agree with ya, David. If every piece of code I’ve worked with was perfect and bug free, I would be a fraction of the coder I am today. The best learning experiences were from wrestling with code that simply would not behave as I wanted. (Phil called programs inanimate. But I disagree. Code has behaviors, sometimes referred to as the ghost in the machine. ;)

    The learning experiences that stick with me most were from making a brilliant design decision that months later looked like the dumbest decision one could have made.

  3. Phil Factor says:

    Some programs seem to pass the turin test but only in their malevolence.

    @JonRobertson Talking of ‘animate programs’ The famous ‘Mechanical Turk’ chess-playing machine turned out to be a real human in the box beneath the board. Heaven only knows how he managed to play good chess like that, but he did.

  4. sdmcnitt says:

    Recently I had to begin supporting a cute new SSIS application. It was a new breed (a mix of Shetland Sheepdog and an Irish Setter) but quite like a DTS.

    Though the app was well behaved in general, however, it had one bad habit that simply had to be addressed — humping.

    Commonly referred to as mounting or “leg humping”, this behavior would happen whenever I logged in and paid any attention to it (especially in front of company or my boss).

    I tried for weeks to cure this nasty bug, working nights and weekends keeping an eye on the thing 24 hours a day.

    In the end I had the application “fixed” and the behavior has not returned.

    The one tip I can pass on to those in a similar situation (especially if fixing is not possible) would be to attempt to transfer the behavior onto a stuffed animal toy — preferably one that you are ready to disgard.

  5. Keith Rowley says:

    I generally agree, but sometime locking up the animal sleeping on the problem overnight, or just walking away and thinking about something else for a while, helps me find the answer I am looking for.

  6. Lee Dise says:

    On a project long ago and far away, back when this sort of thing was new, we were porting a major application from an environment built on IBM mainframes and IDMS databases to one constructed of Sun workstations, Unix, and Sybase — and let’s not forget Ada, in which the military had misplaced a great degree of faith as the solution to all of their managerial problems. U.S. Air Force officers who managed programmers would often say, “You don’t have to be a programmer to manage programmers,” and this is undoubtedly true, though I might question the validity of the Air Force’s corollary, which was, “You have to be a pilot to manage programmers.”

    A crucial requirement of the new system was that it had to continue sending jobs to the mainframes, until the mainframes were laid to their final rest, and collect and collate the outputs. This meant writing code that would dynamically generate a JCL job stream, as well as multiple BCP calls to pull in the resulting data.

    Management had somehow put off assigning this task until the very end. Their lack of planning did indeed become an emergency on our part. The penetrating eye of Sauron focused with myopic interest and potential wrath on any who would contribute to the glowing success, or bitter failure, of this deliverable.

    Our secret weapon was a grizzled old programming orc -– we’ll call him Tyrone.

    Tyrone had come from an IBM BAL (Basic Assembly Language) background; he knew everything there was to know about OS/MVS, and was quite adept at COBOL, PL/I, and Fortran. Nobody I have ever known anthropomorphized the machines more than Tyrone. But theirs was a dysfunctional relationship. Tyrone treated them as if he were a tough cop facing down a street gang, threatening and cursing at them constantly, while the computer gang retaliated with calculated passive-aggression.

    Tyrone was given about six weeks to do the job. I think he completed it with two weeks to spare.

    Like us mere mortals, Tyrone would start by breaking his problem down into smaller, more digestible pieces. But for him, those pieces must have looked something like this:

    1. Make pot of coffee.
    2. Get carton of cigarettes.
    3. Get banana.
    4. Learn Unix.
    5. Curse at the computer.
    6. Learn Ada.
    7. Give the computer the finger.
    8. Learn FTP.
    9. Take a smoke break.
    10. Learn Sybase.
    11. Learn BCP.
    12. Tell everyone in the office (again) how someday he was going to restore his beloved 1956 Austin-Healey.
    13. Write code.
    14. Deliver code.
    15. Take smoke break.

    All of that, to say this: early in my career, I once asked a project manager, what did he look for in a programmer? He replied that there are two types of successful programmers, and you need them both.

    One type is the careful designer and planner who needs time to get it right, but it’s a work of fine engineering when he’s done.

    The other type is the fellow who can get almost anything done in a month, but, for your own sanity’s sake, don’t watch or listen to him work. And whatever you do, don’t inspect the final product too closely or critically.

    That latter type would be Tyrone. I looked at just enough of his code to avert my eyes quickly lest I turn to stone. But he always delivered.

    What must seem, to someone outside the profession, like a breach in mental health can be a necessary and even proper reaction to the stresses of deadlines and unrealistic managerial decrees. It seems only natural to get irritated by computers — the logic was written by people, after all. Who is better at irritating us than other people?

    I always anthropomorphize my computers. And I always refer to them as “he”, never “she”. Once, a female programmer, apparently miffed at my reflexive sexism, demanded that I explain why computers are masculine? “Because,” I replied, “Women just aren’t that perverse.”

  7. Mark A. Tremel says:

    Phil,

    You phil-osophical genius. You are the idiot-savant of analogous reasoning. In short, I envy you. I like the programming problem is a wild beast analogy you paint for us, because it also helps to illustrate why we must at times stay till all hours to finish a task. Were we taming a lion, we would not walk away from his stare just because the whistle blew. There are times when I absolutely dread Friday afternoon for fear that a bug will materialize. If it does, I just cannot put it aside for two days and my weekend unfortunately gets delayed. My wife tends to dread this also.

    Mark Tremel

  8. Javier says:

    Actually , attitude will get you lomg ways. Computers as of today , don’t read your actual mood , but they act as props of your subconscious mind. Every act of creative programming is a little exorcism , a little psychotherapy session , and , yes , some animal taming lore.

    But carefull , not all the animals are the same , nor do they need the same approach. Some respond to subtely , some to brute force , some to simpaty , some to discipline. The only true rule , is never to give them the back while you are taming them.

    Some problems need finesse , the right balance of a heavy hand and cuddling , like the refactoring of the Big Ugly Legacy Monster. Some need subtley and a devious mind , like hardening financial systems.

    You cannot get them all in the same bag , and can’t put a dog wishperer to tame beganli tigers.

  9. paschott says:

    Been in that “get this fixed at any cost” zone before and it takes its toll. I remember going on vacation, but using a lot of that vacation to teach myself a new programming language to rewrite a process into something that could be easily scripted and automated instead of relying on some odd conglomeration of batch scripts and calls to buggy programs. I had a couple of hiccups when implementing, but those were a far cry from the constant “what’s wrong this time” visits I used to get. :)

    Now, I really try to write things that don’t require wrestling with code for an extended amount of time once written. (Not always successful, but I try.)

    We’ve been through a couple of those “grab the code and show it who’s boss” moments at my current workplace. They invariably lead to a couple of people working fiendishly on the offending code to refactor/replace/remove it while also doing their other tasks. Necessary at times, but it takes its toll on the workers for a little while afterward.

  10. Robert Young says:

    – Sometimes development tasks are so complex that they become, to superstitious humanity, rather like a wild beast that needs taming. A programmer cannot allow a problem to get the upper hand.

    Some meme’s come to mind.

    from carpenters:
    “Measure twice, cut once.”

    from doctors (well, may be):
    “An ounce of prevention is worth a pound of cure.”

    from waterfall developers:
    “Design it right the first time.”

    from Agile developers:
    “You’ll never know what the requirements are until the application is finished, so don’t try to get it right the first time. Just keep iterating until the screaming stops.”

    from RM zealots:
    “Put the logic in the data, not the code, so it’s easy to change just by updating the schema.”

    from client-centric coders:
    “Do everything in the client.”

    Note that each is in conflict with the rest. Why can’t we all learn to get along?

  11. jerryhung says:

    Mnn, can we send the bull terrier away and let it become somebody else’s problem? :)

    That’s what people do in politics right? we should do the same

    Eventually, when one becomes the “last man standing”, the buck stops here and you have to fix it anyway, so I’m at least proud that I can fix most problems and the buck stopped

Leave a Reply