Blog:

More from Turning Left Against Traffic:

Copy, Paste, Apocalypse

Feb

The Trouble with Christina

Three-Click Monte

Jan 2009

Your Device Hath Foretold

The Expert Detector

Dec

A Tale of Christmas Design

The Assignment of Madness

Nov

Salary Signals

Sep

Truth in Unplanned Advertising

The Benefit That Wasn't

Aug

Arsenic and Namespace

Information Control

The Unexpected Patron

The Assignment of Madness
Posted 19-Dec-2008 by Robby Slaughter (@robbyslaughter)

Buried in the darkest reaches of an obscure literary work lies a long block of printed symbols. The shapes detail a set of utterly exact instructions, written out as a convolution of asides upon asides posing questions nested within comparisons. For several days, I wrestled these twisty, baffling passages of logic, working to decode the message intended by their maniacal creator. This agony was my job. I was hunting a software bug.

What happens to programmers who go hunting for bugs and fail.

Archaeology by Screen Light

The vast repositories of computer programs hiding out in the world’s memory banks, hard drives and compact discs are mostly silent and invisible. Each miniscule, arcane sequence of bits flutters by in an unfathomably small fraction of a mere instant. When you stare down a blank screen before composing an email or authoring a term paper, the cursor blinks back at you patiently. Each ticking of this digital metronome does more than mark the time. In that half second, billions of calculations whir inside the tremendous electrical machinery of the computer. While you ponder, it thinks. Sometimes, something goes wrong.

A software failure, therefore, is effectively unpredictable and astronomically rare. This claim might seem contrary to popular experience, which insists that computers not only crash frequently, but that they seem to have a preternatural awareness of inconvenient times to shut down. Finding the source of a problem in a software application is like searching for just one typo in the entire Library of Congress, except all the tomes are written in an incomprehensible language and no one can check out a book until you find and fix the bug. Tracking down a program defect is part detective work but mostly anthropology. To correct the mistake, you must get inside the mind of the person who created the problem and understand what they originally meant to achieve.

A Taste of the Quest

This particular bug hunt happened to occur in a bit of client-side web application development, where errors manifest themselves as erratic behaviors on otherwise mild-mannered web pages. The offending code lay inside a free toolkit called Prototype. Open-source libraries like this one are widely available across the Internet, traded like family recipes at a midsummer church picnic. Quality varies, but Prototype comes with an impressive reputation. Not only does this code produce certified county fair blue-ribbon results, but any ambiguity in the printed directions or troublesome ingredients has been mostly eliminated through rigorous kitchen-to-kitchen peer review. Any imperfections that remain will be maddeningly difficult to resolve.

Channeling equal parts record-crawling historian, experiment-waging scientist and soup-tasting chef, I trudged through four thousand lines of code in search of the bug. Hours peeled away as I wandered down false paths. Eventually, the culprit emerged somewhere in line number 1,908. If removed, the remainder of the program operated without a catastrophic crash but also without the desired overall result. Predictably, line number one thousand, nine-hundred and eight is devastatingly complex. These following 152 characters contained the source of the bug:


     elementStyle[(property == 'float' || property

       == 'cssFloat') ? (Object.isUndefined(

       elementStyle.styleFloat) ? 'cssFloat' : 

       'styleFloat') : property] = styles[property];

Three Easy Pieces

Probably no engineering technique is older than delegation, which insists that you can create a more powerful system by blindly relying and building upon other components. Just as you don’t need a degree in pharmacology to benefit from an aspirin or an understanding of electromagnetic radiation to place a cell phone call, computer programmers voluntarily ignore some details by way of assumption. The hallmark of delegation in code is the hallowed parentheses. Just like in the English language, this curvaceous pair indicates an aside (which can be treated as largely superfluous.) Without the middling details inside parenthesis, the code fragment becomes something more manageable:


     elementStyle[ something ? 
       another thing :

         property ] = styles[property];

Just as electrical circuits route current and plumbing valves redirect liquids, information processing systems evaluate information to determine what happens next. This act is broadly titled comparison, and it implies measurement. The usual technique for conducting a comparison are the keywords if and then, but the programmer of this part of Prototype opted for an abbreviated form using a question mark and a colon.

Shortcuts

The bit with the question mark is called the ternary operator, and in many computer languages is just a way to express a conditional with even fewer characters. Instead of typing:


        if it_is_raining then 

          stay_inside

        else

          go_out_and_play

Programmers can save a few keystrokes with:


        it_is_raining ?

          stay_inside :

          go_out_and_play

The syntax of A ? B : C is philosophical contemplation and devoted action. It asks the computer to consider the contents of A, and if this speaks true, pursue B. Should A prove false, the machine must diligently execute C. Simply: If A, then B; otherwise, C. This is the essence of comparison. In the offending source code above, the outcome shall be one of two options on either side of the colon. Either the delegation noted by another thing, or the mystery meaning of property. We can note this choice as a result, and simplify again:


     elementStyle[ result ] = styles[property];

In this final form, the overall purpose of this code snippet reveals its connection to the dreaded Algebra classes of our youth. The equals sign stands for assignment, or the assertion of equality. Before reaching this crucible in the program, the symbols elementStyle[ result ] and styles[property] might be entirely unrelated. After this point, they must be the same. In this epic battle for monoculture, right is might. Whatever information that resided in the left-hand side of the equals sign is forever lost. The meaning of elementStyle[ result ] is forcibly changed to match the meaning of styles[property]. These are the immutable laws of the State of the Machine: right beats left, truth trumps falsity, delegation hides details.

The Mystery Revealed

Easier to Read than Write

The next question is one for the social scientist: why and how did this issue develop? A reasonable theory is that began its existence as a simple assignment:

    
        elementStyle[property] =

          styles[property];

Later, it was determined that elementStyle[property] was not always adequate. Sometimes, elementStyle['styleFloat'] would be needed. This was likely inserted:


        elementStyle[(some condition) ? 

          'styleFloat' : property] =

           styles[property];

And then (some condition) was expanded and expanded until the code became practically unreadable. To see present world: repeat for millions of lines of code, millions of projects, millions of programmers.

My analysis uncovered the programmer’s original, fundamental desire: to correctly establish the value of elementStyle[ result ] to be equal to a previously defined styles[property]. His or her error lay in the folded layers of delegation and comparison which comprise result. Further investigation showed that certain situations involving older browsers and other preconditions led to nonsense in those computations. Adding extra checks in earlier code averted the problem. My patch restored the program and my sanity.

Writing software is hard because reading and debugging code is a pathway to madness. The more quickly we produce new software applications, the more likely future maintainers will be combing through our relics to ferret out microscopic yet critical inconsistencies. Programmers should take greater care to author code designed not just to be executed by the computer, but understood by tomorrow’s software engineers. Managers must understand that one line of code might take a second to write but a month to repair. Users should have patience and offer comfort and appreciation to those who brave the fields of near-insanity. A billion thoughts flicker in the soul of the machine while you wait. Once in a while, wink back.