Inkwell: Authors and Artists

    
I just finished _The Bug_ yesterday, and I have to say I found it more
enjoyable than _Closer to the Machine_.  I think you have a gift for
fiction, and not just for explaining the technical side of computing. 
I was involved in the culture you describe at about the same time (I
was a 30-something programmer--a Senior Software Engineer,
actually--with a small VC-funded Silicon Valley startup in the
mid-80s), and what you describe brings back many memories.  I can
remember the same kind of tensions among the developers, but faced with
a demo-killing bug, everyone pitched in (competed, actually) to find
it.

I agree with <ari> that the book would have been stronger with just a
short epilogue wrapping up the finding of the bug.  If you had put all
of the details in an essay, an appendix, or on the web somewhere, I
probably would have read it, but the book itself would have been more
satisfying without so much technical detail at the end.  (BTW, isn't
there a more glaring error in the inregion function as printed than the
flaw you point out?)
  

    
I love the cover art, and the look and feel of the book. It's very
well crafted. Did you have a major role in that aspect of publication?

Possible spoilers:











I thought the actual bug UI-1017 was very interesting, and exactly the
kind of maddening thing that could happen. And of course the irony was
that it wasn't Ethan's after all.

But I did find it unlikely that Ethan would not have scoured his
nemesis' code and have found the bug. And also unlikely that his boss
wouldn't have handed over the debugging to another programmer after
Ethan hasn't found the bug in a reasonalbe time, maybe a month, for
something so visible. Also, you didn't mention walkthroughs. Were they
not in use at the companies where you worked?  Of course, you wouldn't
have had a story if he had found and fixed the bug.

(slipped with similar comments)
  

    
Lest my original comments be misunderstood, I really loved the book, for 
all that I had complaints about the ending.

And I've known enough people like the characters in the book for it to 
ring true - it's a rare book about people that I can relate to, that has 
enough to say, and is sufficiently compelling, that I can hand it to 
someone who =doesn't= know or care about programming and expect them to 
get caught up in the story, as well.
  

    
Even though I'm not a programmer and have never really worked closely
with any, one thing I like most about "The Bug" is that it's about
people's work lives, and it takes them very seriously.

Yes, it's a little over the top that Ethan sees catching the bug as
almost a life-or-death struggle, but it's believable given the overall
disaster of his personal life that things would get overwrought at
work.

And even for people who aren't neurotically obsessed with their jobs,
work is such an important part of our lives, a place where we can
achieve things and where relationships with other people can be quite
dramatic. Plus, I just find learning about other people's work to be a
lot more interesting than yet another "my mother has cancer" novel,
which is my way of getting around to complaining that work doesn't
figure as much in contemporary literary fiction as I wish it would. The
exceptions, like "The Bug," or Mark Costello's wonderful "Big If,"
which is about secret service agents, are so welcome.
  

    
Greetings to you, Ellen, Laura, fellow WELLbeings, and the public at
large.  Pardon me for arriving late to the party.  I'm just catching up
on this fascinating discussion and I have to say that I've been
intrigued by the subject and am looking forward to reading the book.

I was a programmer at the University of Southern California when I
decided to relocate to the SF Bay Area in 1981.  I got involved with an
outfit called Mandala Information Systems, that had created a product
called MADIC (Manufacturing, Accounting, & Distrubtion Information
Control).  MADIC teamed up with a hardware vendor called Industry Data
Systems, and the two entities worked in concert, later merging (with
some VC) to form MADIC Corporation.  When I first got involved with
them, they had exactly eight customers.  Then, from 1981 through about
1985, their customer base grew from eight to several hundred.  A great
many of their customers were Silicon Valley start-up companies,
including Solectron, Adaptec, Vitalink, Zentec, Intersil, KLA
Instruments, Altos Computer, Tab Products, Wyse Technology, Paragon
Diagnostics, ELXSI Computer, Corvus, and many others.

23 years later, ironically, there are exactly eight customers left in
the world who are still running MADIC, and I, despite my many efforts
over many years to distance myself from it, am working for one of them
now, supporting and maintaining MADIC.  Well, that's one thing that
hasn't been "offshored" to India, and I doubt that it ever will be. 
But it's likely that there will soon be only seven MADIC installations
left in the world, as the one I'm working for is currently preparing to
migrate to MSBS Great Plains ("great pains?" - no, just kidding...).
  

    
>(BTW, isn't there a more glaring error in the inregion function as
printed than the flaw you point out?)

Aieee. Yes there is. A typo of terrible proportions. (One of several.)

The publisher did not use my electronic files. Instead, the entire mss
was retyped by hand, introducing some truly howling typos, not just in
the code. But the code samples, as you would expect, got the worst of
it. 

Since you always have to turn around the galleys very quickly, it was
all I could do to just get the code to look reasonably like C. Alas,
several errors got by me. They were fixed in later editions, but the
whole experience was sort of Ethan-Levinish. I had to console myself
with the thought that it was a book about, yes, a bug.
  

    
>23 years later, ironically, there are exactly eight customers left in
the world who are still running MADIC, and I, despite my many efforts
over many years to distance myself from it, am working for one of them
now, supporting and maintaining MADIC. 

Gerry, this is just wonderful. I have been thinking for months about
old computers: What exactly are we saving when we preserve them? How
would we feel if we could look at old code running? Part of it is
something from the Y2K era, a company that had some very old systems
that it wante to keep running, so they just reset the internal clocks
to a date in 1974, adjusting the dates on reports to show 2000, etc. I
loved the idea of this old computer running on and on in its own time
universe, just doing what it had to do.

I'm assuming the MADIC customers are similar. They like the old system
and, given all the bugs in new systems, they mean to stick with it. 

Another good side-effect of old systems: security. Hackers are not
going to spend a lot of time figuring out how to crack into a system
with eight users. For the longest time, I kept my email on a Win95
system with a very old version of Netscape, a system so obsolete no
virus-writer bothered to fool with it.
  

    
In spite of the disclaimer in the "Programmer's Postscript," I was
really impressed at how accurately you captured the state of computing
in 1984.  Several times I thought "there's an anachronism" but then
reconsidered and convinced myself that, yes, the technology in question
was around then after all.  Did you have to dig around through old
listings and manuals to check your memories for fidelity to the era, or
do you just remember the period that well?
  

    
Good points, Ellen.  It reminds me of a great maxim by Glenford Meyers
(_Reliable Software Though Composite Design_ and  other titles):

  "Programs have long lives."

How many times have we thrown together some "quick & dirty" program to
deal with what is perceived as a temporary problem, and then discover
much later that it became a regular production process.  It's happened
to me several times.
  

    
Sure, and there are also the projects you work on for months of years
and get cancelled, never to be seen again.  Just to balance things up.
  

    

   reminder: readers who are not already members of The Well can
             join in by sending questions, insights, comment, or
             other contributions to the discussion --

                  inkwell-hosts@well.com
  

    
>>>The publisher did not use my electronic files. Instead, the entire
mss was retyped by hand...<<<

Is this standard practice?
  

    
>Did you have to dig around through old listings and manuals to check
your memories for fidelity to the era, ordo you just remember the
period that well?

I have old manuals and friends who are old programmers. David
Rosenthal, who programmed the Sun 1, caught several anachronisms in an
early version, and I'm indebted to him for that. I myself was
programming in those days, so much of it is from memory (though I, like
you, had to stop and ask myself, Did we have that stuff then?)

I did write to Sun to find out exactly when they released their first
system with a mouse. It was 1983. They took some time to answer. One
thing I am learning is that computer history is almost being erased
behind us. Except for the Computer History Museum and one or two good
websites, everything we once knew seems to be evaporating. And a whole
generation of programmers is now in their fifties and sixties and won't
live forever.
  

    
Ellen,

The thing i found most interesting about The Bug was the developing 
relationship between a tester and a programmer. I've really liked your
essays, but i don't think you'd address testers before. I am a testing
consultant (like the later Roberta) and a really big part of my
practice is trying to find ways to get testers and programmers to deal
with each other as humans. It is very common for alienation to set in
and for each group to start believing untruths that allow them to
objectify the other. The developers believe that the testers are failed
programmers and obstructionists and the testers believe that the
programmers lack discipline and don't care about quality. And then when
it gets really bad, both actually start behaving as expected, which
only reinforces the antagonism.

It can be a horrible dynamic which is unfortunately only enforced by a
lot of industry "standards" and "maturity models". Some of these
encourage testers ("quality assurance") to monitor whether the
programmers are following processes correctly (documentation, or unit
testing, or whatever). Others try to treat testing as a black box
activity where testers are supposed to just compare the software
behavior against the specification, and if they aren't given a complete
spec, the they should just refuse to test. This kind of horrible
advice is sadly standard fare in the industry.

I have found that testers who are able to establish human
relationships with programmers are the most effective. Instead of
demanding a specification, they can simply ask about behavior they
don't understand or find confusing. And they often gain insight in to
how and where bugs get into the code.

Thanks for showing how Ethan and Roberta have to get over the
prejudices and learn how to understand the other better before they can
actually get the bug fixed.

Bret Pettichord, Software Tester
  

    
Speaking for at least one publisher, no, it is unusual these days for a 
publisher to rekey a manuscript. But programming is not the only 
discipline where things can go wrong.
  

    
When I edited "The Salon Reader's Guide to Contemporary Authors,"
Penguin (and that means the whole group of publishing entities under
the Penguin Putnam umbrella as well) was still rekeying manuscripts. It
was insane.

The text -- which contained contributions from over 100 different
writers -- had to be edited by me to begin with, and the formatting was
a bit more complicated than the usual because it involved entries with
the author's name in boldface in one size, the birthplace/date
smaller, a italicized listing of the author's books, etc. I remember
asking the editor if they wanted me to input whatever formatting codes
were needed, at least for the bold and ital, since I had to go through
and make sure this stuff was indicated somehow in the ms anyway. (I
believe they were using Quark, but could never get a straight answer.)

This was clearly something that set off alarm bells for them, since
she rushed to tell me not to do anything of the kind. The operative
principle (which in retrospect, I can understand) is to keep an
unbreachable wall between the author and the design/typesetting
process. 

That seemed silly and inefficient to me, but it was nothing until I
learned that the ms that I had submitted on paper and disk had been
copyedited on paper, sent back for my consultation, then, after I
returned it, given to a typesetter who keyed the whole thing in all
over again, introducing new errors that had to fixed in the proofing
stage. I was mad! Checking all that stuff was so dreary, since I had to
make sure all sorts of facts, like publication dates were correct (the
main source on this, Contemporary Authors, is notoriously
error-ridden) by laboriously using the Library of Congress web site.
Oy.

I kept asking why they did it this way, thinking maybe there was some
deal between the publisher and a typesetters' union. The editor, who
was a very smart young woman, kept saying "this is the way we've always
done it." That's the wall you hit in big book publishing. They do a
lot of stuff that now seems nuts because that's how they've been doing
it since way back when. Tradition is like a physical force there. 

Things that seem like adaptations, like having me send the first ms on
disk as well as paper, are even more absurd because as far as I can
tell no one ever used the thing. It was copyedited on paper and I
assume the typesetter rekeyed it from the paper version with the
copyedits.

This, incidentally, is one reason that publishers rarely seem to have
a final version of a book in digital form. I think only the typesetter
does. People at Salon are always baffled by this, but it's a
continuation of how the printing process used to work, where the
"boards" were kept by the printer. (Likewise, everyone also assumes,
incorrectly, that real figures on national book sales exist somewhere,
which is not the case.)
  

    
I should add that if Ari works for a small publisher, things are
probably done a lot more sensibly. Small publishers have to be
efficient.
  

    
I worked for a rather large publisher (Addison-Wesley) co-owned by the
same folks who own Penguin (Pearson), so g figure. Most recently I typeset 
a book in Hebrew for Jossey Bass, part of whose production process 
involved writing a program to convert from the Israeli typesetter's files 
to ones I could use. So, it can be done and is done.

But, the main concern of any production editor (note the word 
"production") is whatever lends sanity to the production process. 
Sometimes using a familiar production route with known ways to keep things 
checked, proofread, and fixed, is worth a lot. I've had Production Editors 
hide author's corrections rather than introduce new variables (fix the 
errors) close to the print date. In that regard, I suspect that they are 
much more similar to Release Engineers than not ;-).

One of the thing that I really liked about "The Bug" is the way it 
captured the little I am familiar with of what happens when a company is 
somewhere out there on the bleeding edge, and still has to deliver 
tangible stuff on a defined schedule (or pretend to). There are so many 
interesting variants on "reality".
  

    
Enlightening. Thanks for the information, Ari and Laura. 

Book publishing must exist in this strange old-new world. On the one
hand they now sell books like hamburgers are sold; they're commodities.
On the other, they re-key manuscripts like scribes in monasteries. 
  

    
That explains the success of production houses like the one I just did an
editing job for. Everything in MS Word with a clean array of styles,
revisions, notes--the way it should be done. Their client was Wiley.
  

    
Ellen, I'm interested in the way you mixed first- and third-person
narrative.  What led you to make this choice?  Do you think that having
the initial section (before the flashback) in the first-person draws
the reader into the story?  You've said here that you feel that both
characters are you.  Did the way Ethan's story ends motivate you to
pick third-person for his parts?
  

    
Bret writes:


I published a book with Wiley. There process was electronic, but this
only raised the opportunity for different problems. A proof reader
decided to run the entire manuscript through microsoft word's grammer
checked using the default settings. So every final preposition was
recast. I actually compiled a list of 18 or 19 changes that were
systematically made and which a co-author and i had to systematically,
but manually, revert. It was only with hindsight that i realized that
these 18 changes were actually the settings in word's grammer checker.
  

    
Ick.
  

    
and scarier still, Wiley is the gold standard for editorial quality
amongst the larger publishers.
  

    
>Ellen, I'm interested in the way you mixed first- and third-person
narrative.  What led you to make this choice? 

I'm not sure "choice" is the right word here. The book started in my
mind as an extended essay about a bug I once had -- the bug upon with
*the* bug is based. Like Ethan Levin, I couldn't solve it for about a
year, and my life wasn't exactly going so well at the time. I thought
it would make a decent novella-length essay, something that would
introduce "civilians" to the messy process of writing software. This
was during the dot-com hysteria, and I also thought something about the
soft underbelly of software might be a good antidote to the madness.

So I started out writing it in the first person. For reasons too
convoluted to go into, I felt that the "truth" was too confining. The
actual experiences of my life at the time did not seem all that
interesting for other people, and I began to think of the story as
fiction. I think went through many interations -- first person by a
woman, first person by a man, third person all the way through, etc.,
until I found my characters Ethan and Berta.

In the end, I knew I wanted it to be narrated in the first person by
someone who felt responsible for what had happened (Berta, the tester).
But sticking to her first-person point of view was very limiting;
everything she would say about Ethan would have to have the horrible
distancing problem of "surely he felt this" and "I assume this
happened."

Actually it was Laura Miller to finally gave me the push to just
change point of view. She read an early manuscript that used both
first- and third-person (Berta, then switching to third-person but from
Ethan's point of view), and she said, Well, you can just have this
third-person viewpoint without explaining where it came from. And I
thought, yes, that's exactly right. 

I was reading an interview with Jeffery Eugenides, and in it he said
that for his first book he had imposed strict narrative rules upon
himself, but in writing Middlesex he had taken "every liberty." This
was after I'd written The Bug, but bhat phrase has stayed with me as
very wise.