The Bug 273
| The Bug | |
| author | Ellen Ullman |
| pages | 368 |
| publisher | Doubleday |
| rating | 8.5 |
| reviewer | Trevor Stow |
| ISBN | 0385508603 |
| summary | A programmer 's life unravels as he struggles to find a bug. |
In fact, The Jester seems to have an impish intelligence of its own, laying dormant for weeks somewhere deep in the libraries of the company's ground-breakingly new GUI front end. When it does surface, it's usually during a sales presentation, causing a complete system failure: garbage on the screen, frozen keyboard. It's enough to frighten any and every potential customer. For a start-up still living on venture capital funding, this is a bad thing.
As if the stakes weren't high enough, our hero, Ethan, isn't exactly a well-rounded Renaissance Man. He has a single friend at the office, and they barely talk. Otherwise, Ethan is irritable, distant, and often loses himself in his own logic-gated thoughts. He suffers moments of mild panic where he doubts his own competency and frets over not having an advanced degree. Plus, his fellow coders are a petty, snide-commenting bunch; meetings degrade into profanity-laden shouting matches, passing the blame, etc, all of which spurs Ethan to work harder. He autopilots through dinner while reading a Unix manual, works from home, and falls asleep in his clothes.
None of this leaves room for Ethan's girlfriend, Joanna. At the story's beginning, she goes to India for a month with her male friend Paul. Ethan can't go, citing the importance of his work. Paul's wife can't go either. We see where that's heading.
Ethan's life begins to unravel. He associates his personal problems with The Jester. Once that damn bug's squashed, he tells himself, the rest of his life will stabilize into some happier space.
The story's narrator is Roberta, who speaks to us from the early 2000s, remembering her job as the QA tester who worked most closely with Ethan. Roberta does have an advanced degree, in linguistics, but jobs in academia are scarce, and what else do you do with a degree in linguistics? At first, Roberta dismisses the programmers as a gruff, dismissive pack of dorks, just as they dismiss her because she can't code. A frosty wall separates the two sides of the product development team: those who write the bugs, and those who find them. In her evenings, Roberta composes poetry and suffers her own anxiety over abandoning a higher education for a plain job in IT.
Eventually, though, Roberta learns to program in C, and that's where The Bug shines brightest, touching on some sparkling insights: the nature of life, the nature of time, the cold beauty of code, and ourselves, living side-by-side with computers that are not, alas, alive. Stuff that will stick with you.
However...
I was disappointed with the book's end. If you program for a living (as I do), you will see parts of yourself in Ethan. But hopefully, you aren't Ethan. Even if you have no friends, no girlfriend, nothing, you still might play video games or watch TV or something (read?). Ethan, it seems, makes no effort to find even brief happiness. His life is joyless. And that's probably why I didn't like the ending. The book builds so well, keeps a quick pace, with smart dialog, rich characters, suspense, and very high stakes: I felt the pay-off could have -- should have -- been much grander.
Ellen Ullman, who also wrote Close to the Machine, was a programmer in the 80s. I caught her interview on NPR, where she explained that Ethan's story and The Jester were very loosely based on her own pursuit of a bug while working at Sybase.
You'll probably enjoy The Bug, even if you don't like computers and write poetry for a living. It's adult fiction and feels contemporary without trying to be 'zany' or 'hypercharged.' It's not a funny book, but rather a calm, wise walk into unexplored story matter, with lots of interesting bits to think about.
You can purchase the The Bug from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Hardly realistic (Score:5, Funny)
Re:Hardly realistic (Score:5, Funny)
Re:Hardly realistic (Score:3, Funny)
Your still in college, aren't you?
In the real world, compromises have to be made. The later a bug is found in a product development cycle, the more expensive it is to fix it. Once you reach a certain point, you are going to just have to learn how to live with just about everything except for a drop-dead fatal error.
Re:Hardly realistic (Score:5, Funny)
Oh the irony.
Re:Hardly realistic (Score:2)
Your still in college, aren't you?
Bill? Is that you?
Re:Hardly realistic (Score:4, Funny)
What about their still in college? Are you suggesting that they supplemented their income to pay tuition by moonshining? Egad!
Re:Hardly realistic (Score:5, Funny)
Yeeeah.... I can see it:
...there's a nasty bug with the GUI, but stay calm, it only represents itself when you're using a monitor, as long as any terminal of any type isn't connected to the PC, it won't bother you....
<from the doc>
</from the doc>
Re:Hardly realistic (Score:5, Funny)
debuggery - maxims and arrows
- be hostile: your application was your friend - your baby. you gave it life. well, no longer. now your application is your enemy. do you admire the intricate house of cards you have built like hiram abif? don't. you have a glue gun now and you are going to do a little explaining about who is boss here! your app is taunting you - it's thinking "what does a chemical/analogue hack like that have that i don't?" well, i'll tell you: an index finger. suitable for hitting the "del" key. make this crystal goddamn clear!
- kludge everything! the debug stage of the development life cycle is all about kludges. we call it klop - kludge-oriented programming:
- blame others: teamwork is just a code word for being the shepherd to a flock of scapegoats. if you were smart, you'd have been working on cultivating a culture of accepting blame early on in the cycle. this is espescially effective if yr building a client/server thingy. establish early on that most of the failures are on the client(server) side. whichever one you're not writing.
- redefine feature sets. the client is a clueless little doughboy who can't tell his ass from his operating system anyway. he's been flaking you on the spec-n-req all year. turn those tables! if a feature is buggy, yank it. if there's a complaint, reference the client to some vaguely-related advisory somewhere (trust me, he won't read all the way down). if he complains say "in light of advisory x we strongly adivse against implementing _______ (feature). a work around may be possible at a future point and we are more than willing to calculate the billing for that additional work now."
all that and echo will solve all yr debuggery problems.kludge foo = new kludge(specialCase bar);
you've written that. the debugging phase comes at the end of a project. ie the part closest to the deadline when clueless suits and moneyment[1] confuse line count with product. the pressure is on. the company is on the line. are you going to walk into the glass tower and pitch to the vc's about how yr going to have to go back to the uml's and rebuild x? good luck! can i have your job when you're done? get the tape, get the staples, get the glue.
make yourself documentation czar if possible - then abuse the position to retroactively assign blame to other team members ("the docs explicitly state that we use roman numerals" - "gee, i don't remember that" - "well tough. get coding").if you set it up right you can build an army of debugging minions to do your kluding for you while you, uh, write in your blog...
Re:Hardly realistic (Score:3, Funny)
Hey, you've been spying on us, haven't you! I told the boss we needed to get a patent on our development process ASAP, dammit!
Re:Hardly realistic (Score:2)
Re:Hardly realistic (Score:3, Insightful)
Re:Hardly realistic (Score:2)
This isn't always possible. A bug that can't be reliably duplicated is difficult to pin down in a debugger, and a bug that you have no idea of the root cause of can't just be removed with a code rewrite - you don't know which block of code to rewrite.
The hardest part of debugging is identifying where the problem is. Once you know that, you
Spolier WARNING (Score:5, Funny)
Re:Spolier WARNING (Score:3, Funny)
He probably comes back from the future with a shiny, flying Delorean with a souped up blender on top of it and a SERIAL CONSOLE. (not embedded on said Delorean, duh)
Re:Spolier WARNING (Score:2)
Spoiler? (Score:3, Funny)
Re:Spoiler? (Score:5, Funny)
He uncomments:
work();
Re:Spoiler? (Score:2)
Its a she...yeah a female debugging in 1980!!!
Re:Spoiler? (Score:2)
Re:GCC! (Score:2)
I have not found one single girl capable of writing anything that is maintainable, extendable, efficient, and well thought out. They are simply incapable of being good code designers, but they can be great debuggers.
Yeah, it's their natures. They can't help it, it's that women are physically incapable of thinking logically or clearly. Poor things, they're made for gossip, cooking and sex; we never should have encouraged them to start doing man's work.
Never should have given them the vote in the firs
Re:Spoiler? (Score:2)
On Error Resume Next
You'll just have to wait... (Score:3, Insightful)
The end of the book goes deeper than you suggest.
Re:You'll just have to wait... (Score:2, Funny)
Let me guess, he is intentionally causing the the bug because he has a mental disorder.
Oh my, how deep...
Re:You'll just have to wait... (Score:2)
Thats better then the standard Disney shoot your daddy beginning...
Re:You'll just have to wait... (Score:5, Funny)
In the Stephen King (Richard Bachman, if you want to get technical) version, everybody on the development team has to work until the bug is found, no matter how long it takes. The instant you stop typing, you're shot.
Oh wait. That's MY company. Oh, SHI-----
NO CARRIER
Obviously fiction/fantasy (Score:5, Funny)
Re:Obviously fiction/fantasy (Score:2, Funny)
Re:Obviously fiction/fantasy (Score:3, Insightful)
So you're saying that our entire value as human beings is how well we can debug code? I can understand how someone with your attitude would have trouble with seeing how someone could get a girlfreind....
Re:Obviously fiction/fantasy (Score:2)
Take a chill pill dude. My post was a joke (thank god at least one moderator got it). It plays on all the stereotypes of an uber-geek. When I first typed it, I placed a winky at the end, but then I thought, "nah, why make it sooo obvious". Judging by yours and others posts though, I guess I subtlety
Re:Obviously fiction/fantasy (Score:2)
So you're saying that our entire value as human beings is how well we can debug code
No. Notice how he said geek? A geek who takes that long to find a bug isn't someone to have a lot of respect for. Just like how you wouldn't have too much respect for a doctor who couldn't tell the difference between a burn and a cut.
It's a JOKE people, sheesh (Score:5, Insightful)
Note to self, subtlety is not the best approach on
Re:It's a JOKE people, sheesh (Score:2)
No, the problem is that there was no way to tell that you were joking. It reads as completely serious, if a little non sequitor. This is frequently a problem with written communications, as I'm sure you're already aware.
Re:It's a JOKE people, sheesh (Score:4, Funny)
Sorry, you can't joke about everything. Joking with nerds about their lack of girlfriends is a no-no. You really hit a sensitive spot.
Tor
Re:Obviously fiction/fantasy (Score:5, Insightful)
Plus, anyone who's THAT much of a geek and takes THAT long to find a bug, isn't someone I have a lot of respect for and would really care about anyway.
I see you've never met up with any seriously nasty bugs.
I worked on tracking one down, once (I didn't succeed; another engineer with 20+ years of experience was put on it, and although he didn't either, he got enough of a clue that a third guy with a heavy hardware background finally nailed it). It turned out to be caused by a subtle hardware bug (hooking together two devices with different edge-triggering criteria) that by itself wouldn't have caused any problem, but interacted -- occasionally! -- with a tiny bug in a driver, where the driver was attempting to work around a documented flaw in the ethernet chip it was controlling. That *still* wouldn't have caused a problem, but the embedded operating system we were using could, under certain circumstances, use zero-copy packet handling. The result was that incoming network packets would sometimes get overwritten by newly arrived data while the original packet was still working its way up the TCP/IP stack, or waiting for a thread to get around to processing it.
The appearance of the bug depended on a zillion details, and it went for a long time without being noticed because one of the required conditions for appearance was a heavily-loaded network, so it wasn't until we got around to installing the system at a very large client site that it even cropped up (because of some other required conditions, lab-based stress tests had never revealed it). Exacerbating the problem was the fact that our system was designed for high availability, with each processor paired with a redundant "standby" system. In many cases the active board would fail and operations would be silently taken over by the standby board, further hiding the bug.
That's the worst bug I've ever chased. I was the fourth engineer assigned to it and the first to find a way to reproduce it with some level of consistency (about 20% of the trials). The guy before me was the one who managed to demonstrate that what appeared to be a whole class of random failures was actually (probably!) one problem. By the time it was finally cracked, it had taken six programmers six months, with at least one person assigned to it full-time for the duration.
I said that was the worst one I've ever chased, but I've seen plenty of other really nasty ones. The worst are caused by compilers that generate incorrect code or hardware problems, but I've even seen some really nasty ones that were entirely in my code, as well. Like a subtle bug in a set of B-tree routines I wrote years ago. A year passed between the time that one first showed up and the time I nailed it.
Bugs that are intermittent (and rare), never show up under a debugger and hide somewhere in the middle of tens or hundreds of thousands of lines of code can be extremely hard to track down.
Re:Obviously fiction/fantasy (Score:2)
Well, some attractive girls prefer geeks. It's the attention to detail, the ability to think clearly, the expression of individuality, the drive/motivation, the expression of the creative urge to create something from nothing, an even god-like authority to breathe life into a once-dead piece of metal. While attractive girls who have these qualities themselves and can do these things themselves certainly don't look on in breathless admiration, we also could not settle for someone who did not themselv
Re:Obviously fiction/fantasy (Score:2, Funny)
Look, who cares about all that crap, what's important is have you fixed the damn bug or not?!?!?!? :)
Re:Obviously fiction/fantasy (Score:2)
Steroetypes schmereotypes!
I think we all know who the Jester is (Score:5, Funny)
Common theme: Sales Presentation. Most sales-drones I've ever seen look and act like Jesters anyway.. certainly the promises spewing from their powdered faces seem utterly fantastic and comical at times
Snide-commenting? (Score:5, Funny)
Forgive me, but when I read that, I thought this:
Re:Snide-commenting? (Score:5, Funny)
Shouldn't that be
There's your bug -- you never closed your snicker emote asterisk.
Ben
Re:Snide-commenting? (Score:3, Funny)
Re:Snide-commenting? (Score:2)
Then, when that milestone is done and you're into the bugfix phase, you can sit down and redo the window handling code to fix the original problem and dekludge it. If you think of it as "ref
subject (Score:5, Funny)
Plenty of source material then!
Re:subject (Score:4, Funny)
Sybase == Microsoft (Score:2, Informative)
won't read it (Score:5, Insightful)
I personally won't read it because the last thing I want to spend time on when I get home is . . . more work related reading material.
I don't want to read "about myslf", but rather about something much more entertaining that I don't experience every day.
-n
Re:won't read it (Score:5, Funny)
Give Penthouse Letters a try.
Re:won't read it (Score:2)
Dear Slashdot (Score:2)
I never though I'd be writing to you but the most fantastic thing just happened to me. I work for a small software company, and it's a pretty loose place. The other day I was trying to solve a really nasty bug, and...
Sounds dumb (Score:5, Interesting)
No, sounds like something else... (Score:4, Funny)
The only twist on this one is that the bug takes over the guy's program instead of the guy himself.
Re:No, sounds like something else... (Score:3, Interesting)
Yes! Good! The bug is borne of the coder; the bug would not exist without the coder, though the coder seeks to destroy the bug. Yet, we see that the bug defines the coder -- it gives him purpose, even identity. So, in a sense, he *is* the bug...coder creates bug creates coder. I wonder if, to defeat the bug, he becomes the bug, which he does by realizing that he
End of the book... (Score:4, Funny)
Ethan, one word... (Score:2)
One word.... valgrind.
Plagiarism! (Score:5, Interesting)
Moby DICK. They just replaced some of the names.
The Bug = The DICK,
Roberta = Ishmael,
Ethan = Cpt. Ahab.
Just like Tanya Grotter! Melville WILL sue!
Re:Plagiarism! (Score:3, Funny)
Re:Plagiarism! (Score:2, Funny)
And if they make a pirate movie (Score:3, Funny)
Rated Arrrrrrrrrrrrrrrrr
-B
Re:Plagiarism! (Score:3, Funny)
The Bug = The DICK, Roberta = Ishmael, Ethan = Cpt. Ahab.
Just like Tanya Grotter! Melville WILL sue!
The real threat here isn't that Melville will sue (he is dead, after all).
The problem here is that, if your analogy is true, that means that the great-grandson of Ellen Ullman will become a new-age euro-trash remix artist calling himself "Bug", after his great-grandmother's famous antagonist by the sam
Re:Plagiarism! (Score:5, Funny)
Another Bug!!!!! (Score:3, Informative)
Sounds good. (Score:2)
Re:Sounds good. (Score:5, Funny)
Any ideas where can I find a book that's 'zany' and 'hypercharged'
Here you go. [amazon.com]
Re:Sounds good. (Score:2)
To review the review (Score:5, Interesting)
It's difficult to review fiction well. The reviewer has to tread a delicate line between failing to give enough information to engage the reader, and giving too much information, so that the reader's experience may be spoiled to some degree. In this review, the error seemed to be on the side of too much information-- the stuff about the unsatisfying ending. The reviewer might have profitably left that stuff out, and based his thumbs-down on less revealing matters.
Still, in this case, the reviewer seems hampered by what appears to be a bad case of literary fiction. Or so it appears. If that's the case, then there's not much point in criticizing the book's plot, since in literary fiction, plot is usually secondary to other concerns. No professional reviewer would ever make the mistake of criticizing an attempted literary novel on the basis of the ending, since in such a work, the plot would be subordinate to character development or the artful use of prose.
Of course literary fiction is most often judged on whether or not the thematic content appeals to the reviewer (as it apparently did in this case). Which is why so many literary novels about the angst of academic life get glowing reviews. Yuck.
Re:To review the review (Score:3, Informative)
This does seem to be the case, but it really shouldn't. Anyone who paassed college freshman english lit and who does not possess some memory lapse of the time should be able to evaluate literature on several grounded factors:
Some criteria most reviews cover such as:
who are the protaganist(s) and antagonist(s)
What is the conflict (person v person, person v nature, person v self)? What is the plot?
What is the setting?
What is the point of view?
Other criteria se
Re:To review the review (Score:2)
Because they made the plot suck on purpose, it's invalid to point it out? Bah!
I think the point of the review on Slashdot is to help us decide whether or not we want to read the book, not to conduct an academic exercise.
To review the review of the review (Score:2)
I read this book. (Score:5, Interesting)
The mood is dark, but not too cypherpunk. I can almost hear the florescent lights buzzing through the whole book. Very harsh and simplified.
The descriptions of the team meetings and the QA vs. DEV rants rival Dilbert's distopia.
Buy it for the few sex scenes, and watch out, the PHBs are in their too, not just the 'jester'.
Also, there net admin is so raw. Bring her on!
Re:I read this book. (Score:3, Informative)
Re:I read this book. (Score:2, Funny)
I'd like to read fiction about something *else* (Score:4, Insightful)
I think there's something to be said for being more well-rounded.
Re:I'd like to read fiction about something *else* (Score:3, Interesting)
It is interesting to see someone documenting something where coding is close to what it's really like.
Re:I'd like to read fiction about something *else* (Score:2, Funny)
Isn't that a typical problem among geeks...and a contributiong reason for why they don't have girlfriends?
What gives? (Score:5, Interesting)
Re:What gives? (Score:2)
I don't get it. Is he looking for the matrix or something?
Re:What gives? (Score:2)
Every unsolveable problem has a solution. It's called natural viagra.
Re:What gives? (Score:3, Insightful)
Sounds a bit like there's a problem with the metaphor itself. To non-geeks, the computer bug metaphor is going to be less than interesting. To real geeks, it's just too difficult to consider a computer bug as being something truly unsolveable. I think most of us have fought with obscure, insane bugs, and we've conquered them and become stronger coders in the process.
(A personal case was finding a bug in the newsreader tin that used fclose i
Quick fix.. (Score:5, Funny)
#include <stdlib.h>
void handler(int arg) {
char command[1024];
sprintf(command, "/sbin/reboot");
system(command);
}
int main(int argc, char ** argv) {
signal(SIGSEGV, handler);
}
Re:Quick fix.. (Score:2, Funny)
Re:Quick fix.. (Score:3, Informative)
long pid=getpid();
sprintf(command, "/usr/bin/gdb %s %ld", argv[0],pid);
system(..)
you get the picture..
I like Ms. Ullman's writing, but... (Score:5, Interesting)
I don't think (from reading this book) that she's quite made the leap to writing fiction. The characters were wooden and stereotyped, the problems with "the code" overly dramatic and in the end sorta phony, and the plot was a stretch at best. She was trying to create a tension where none really exists naturally. (A Bug? Big deal, fix it. I do that 20 times a week or more.)
I hope she continues to work on her fiction, because given how talented she is at expository prose and given her deep understanding of the geek existence, she has real potential. (Close to the Machine was excellent!) But for now I would much rather read a writer who learns geek (c.f. Neal Stephenson, William Gibson) than a geek who learns to write fiction. YMMV.
Re:I like Ms. Ullman's writing, but... (Score:2, Insightful)
Ever been assigned a bug so hard to track and understand that it took you a month or more to fix it? That also has visibility to folks in the upper managesphere? There is a lot of tension when you can't just "fix it."
Re:I like Ms. Ullman's writing, but... (Score:4, Interesting)
In 1983 I was working on the firmware for a combination port selector and stat MUX. Two weeks before we were to ship, a bug appeared that intermittently crashed (what we would now call) the NIC.
This was a startup, in a time and place where there was no payroll insurance. In addition to the usual crushing startup pressure, if we didn't ship, the company didn't get paid, so we didn't get paid.
It took four of us the full two weeks to find and work around the bug. We were finally convinced it was a bug in the CPU, because swapping two adjacent independent load-one-register-from-another instructions made the problem go away. We ended our final push, having been up for over 72 hours, by leaving at 6:30am for the three-hour trip to the customer site with two sets of new EPROMs for the units they already had on site.
If you've never experienced tension like that, I want to work where you work!
Salon.com... (Score:5, Informative)
Books like this? (Score:5, Insightful)
I beg to differ - I think its great that a book has such an interesting premise and such a fresh view on literature. I've never seen anything like this, and will probably be picking this book up.
Re:Books like this? (Score:2)
You should also pick up The Old Man and the Sea, by Ernest Hemmingway.
The Bug is a metaphor... (Score:5, Interesting)
But I'll go out on a limb here and guess that The Bug is not just in the computer. Some of the characters are also trying to debug their personal lives. Sorry if that is off the mark or just too obvious. But some of the comments about "I don't need to read about work" might be missing the mark.
Re:The Bug is a metaphor... (Score:2)
Damn! (Score:2, Funny)
Sounds Familiar (Score:5, Funny)
Ah, the classics never die, they just get a bad sequel..
Sounds terribly depressing (Score:4, Interesting)
I am reminded of that scene in This Is Spinal Tap, where the band is standing around Elvis's grave. "Really puts things in perspective." "Yeah, too much! Too much f**king perspective!"
I know it! Here's the plot: (Score:4, Funny)
"But you're out of your mind!"
they said with a shrug,
"The customer's happy,
what's one little bug..."
But he was determined;
the others went home.
He spread out the program,
deserted, alone.
The cleaning men came,
the whole room was cluttered
with memory dumps, punch cards,
"I'm close..." he muttered.
The mumbling got louder,
simple deductions,
"I've got it! It's right,
just change one instruction!"
But it still wasn't perfect,
as year followed year.
People would comment,
"Is that guy still here?"
He died at the console
of hunger and thirst;
the next day he was buried
face-down, nine-edge first.
The last bug in sight,
an ant passing by.
It saluted his tombstone,
and whispered "nice try."
Author unknown. Circa late 1970s
Pinnacle of Programming! (Score:4, Funny)
A Wonderful book (Score:2, Interesting)
a couple of Ethan Levins in my 20 years of professional programming experience. They're not common, but not uncommon either.
For anyone who actually wrote C back before automated heap checkers, extreme programming, web- and script-based development, and other joys of the modern programming life, this book rings disturbingly true.
I have recommended it to my mom and other folks who don't understand what I do for a living.
why did she have to name him Ethan? (Score:3, Funny)
But hopefully, you aren't Ethan. Even if you have no friends, no girlfriend, nothing, you still might play video games or watch TV or something (read?). Ethan, it seems, makes no effort to find even brief happiness. His life is joyless.
It's really weird reading something like that when my brain keeps wanting to associate the name "Ethan" with "me".
Authors, please name all main characters -- particularly those with serious personality flaws -- David. Davids are used to sharing their name with millions of other people. The name "Ethan", on the other hand, should only appear in Penthouse Letters, when describing studly guys with twelve-inch cocks servicing four women at once.
Thanks, I'd really appreciate it.
A good sanity check... (Score:2, Insightful)
For me, the book was a very good/quick read and slammed home the importance of stepping away from the machine and living life. Work to live, not live to work... right?
Jester sounds like the Terminator.. (Score:2)
It can't be bargained with, it can't be reasoned with; it doesn't feel pity, or remorse, or fear! And it absolutely will not stop, EVER, until you are DEAD!
The Last Bug (Score:5, Funny)
Note that "face down, nine edge first" is a reference to an IBM puch card reader which had those words printed on it ("place cards face down, nine edge first"), the 'nine edge' typically being the lower edge of the card where the row of nines were.
Re:whew (Score:2)