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.
