Tuesday, September 23, 2014

The Value of a Yellow Pencil



   As you all know, computers are very picky. You have to have every single dash, period, space and letter correct or you find yourself somewhere off in ‘left field.’
   An example of how important small things are when dealing with computers, Ellen Ullman wrote an article for the May 2013 Wired Magazine.
   “I once programed a system that came to me with a five-year-old bug. The value of a key data element – shrinkage in the customer’s inventory--always came back zero. Our company insisted the problem came from another vendor’s software, not ours; users had all but given up complaining.
   “The code logs showed that six programmers before me had failed to fix the bug. I followed the steps my predecessors must have taken,…but found nothing that accounted for that zero.
   "The company with the five-year-old bug was in downtown San Francisco. Every morning a legless man in a wheelchair sat before the main entrance selling yellow Ticonderoga pencils. He was friendly, and I was always happy to see him. My job was dull. I was staying on with one determination: to fix that bug, then leave. I bought pencils every day.
   "To track down that errant zero, I printed out key parts of the system—foot-high binders of fan-folded green-and-white lined paper with holes running down the sides—then sat down to read. Each time I needed to jump to another subroutine or subsystem, I inserted a pencil to mark the place I had to return to. Soon the floor was carpeted with blue and red binders lanced through with yellow pencils.
   "Watching a program run is not as revealing as reading its code. Entire sets of conditions may not be met, or met rarely, and sections of the program may lie dormant, seldom executed. The print-out, however, shows you everything. You can see the elegance of the programming or the lack of it…and also statements that are beautifully compact but barely legible, without comments, unkind to the next programmer who will come along.
   "And—dare I say it?—you can make notes in the margins with a pencil. Reading code is like reading all things written: You have to scribble, make a mess, remind yourself that the work comes to you through trial and error and revision. In today’s programming environments, objects fly in and out of scope—in and out of executable visibility—like asteroids crossing planetary orbits. If the code is on paper, however, you can cut out sections, tape them to other sections, get an idea of what is executing now, what came before, and what comes next.
   "Above all, paper helps you find bugs.
   "One day, after some 8 weeks of searching, I pulled a pencil out of a listing and saw the reason for the zero. I can’t recall the exact instructions, but a simplified explanation is that the code read:
key_data_element=I_value (capital I, which had been initialized to zero), when it should have read:
key_data_element=l_value (lower-case L, holding the real value.
   "Now this is truly awful programming. No variables should be given such similar names, especially not when their sole differentiator is two letters nearly identical visually. Six programmers before me, looking at code on our white-on-green character screens, could not tell eye from el. All the time I had spent staring into those screens, I could not perceive the difference. But here on paper I was reading slowly; the text was not scrolling by. Even against the lined background, with characters that had been chattered out by a dot-matrix printer—even here my eye sense something was wrong. Suddenly I could see the slight variation; the roof of that capital letter I.
   "I made the change and the bug was gone.
   "I fixed it while my boss was on vacation. When he returned,
he was furious at me, as if I had betrayed him, made a fool of him in front of users who had been assured the the problem was not in our code. I myself was in a cheerful mood. I gave notice."

Ellen Ullman is the author of Close to the Machine and the novel By Blood.

No comments: