Jim Klopfenstein (klopfens) Tue 20 Jan 04 13:01
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?)
a meat-vessel, with soul poured in (wellelp) Tue 20 Jan 04 13:11
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)
Ari Davidow (ari) Tue 20 Jan 04 13:20
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.
s 205 (lauram) Tue 20 Jan 04 16:23
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.
Gerry Feeney (gerry) Tue 20 Jan 04 18:11
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...).
Ellen Ullman (ullman) Wed 21 Jan 04 10:31
>(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.
Ellen Ullman (ullman) Wed 21 Jan 04 10:38
>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.
Jim Klopfenstein (klopfens) Wed 21 Jan 04 11:16
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?
Gerry Feeney (gerry) Wed 21 Jan 04 12:14
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.
Brian Slesinsky (bslesins) Wed 21 Jan 04 12:25
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.
virtual community or butter? (bumbaugh) Wed 21 Jan 04 12:39
reminder: readers who are not already members of The Well can join in by sending questions, insights, comment, or other contributions to the discussion -- email@example.com
Steve Bjerklie (stevebj) Wed 21 Jan 04 14:07
>>>The publisher did not use my electronic files. Instead, the entire mss was retyped by hand...<<< Is this standard practice?
Ellen Ullman (ullman) Wed 21 Jan 04 17:14
>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.
Bret writes to say (bumbaugh) Wed 21 Jan 04 18:18
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
Ari Davidow (ari) Thu 22 Jan 04 06:11
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.
s 205 (lauram) Thu 22 Jan 04 06:46
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.)
s 205 (lauram) Thu 22 Jan 04 06:47
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.
Ari Davidow (ari) Thu 22 Jan 04 07:53
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".
Steve Bjerklie (stevebj) Thu 22 Jan 04 08:15
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.
Andrew Alden (alden) Thu 22 Jan 04 08:59
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.
Jim Klopfenstein (klopfens) Thu 22 Jan 04 09:45
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 Pettichord, again (bumbaugh) Thu 22 Jan 04 10:18
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.
Andrew Alden (alden) Thu 22 Jan 04 12:52
Jim Rutt (memetic) Thu 22 Jan 04 12:55
and scarier still, Wiley is the gold standard for editorial quality amongst the larger publishers.
Ellen Ullman (ullman) Thu 22 Jan 04 13:38
>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.
Members: Enter the conference to participate