Ellen Ullman

He was running the compiler when the bug report came across his desk. The compiler, the program that translates a programmer’s code into machine-readable bits — Ethan Levin had laid his code before its merciless gaze, and now he stared into his screen to see its verdict. Was he aware of the tester passing behind him? Did he take any notice of how carefully she slipped between his whiteboard and his chair, holding in her stomach so as not even to brush against him? No, of course not. Oh, all right: perhaps peripherally. Literally in his peripheral vision he might have seen her, and the thought “tester” might have formed in his brain, which would have led to the automatically accompanying idea that testers only bring news of trouble, and so why bother with whatever trouble she was bringing him now?

He was occupied by other troubles. Warning messages were scrolling up his screen, the compiler’s responses, notices that this and that little thing in his code might not be legal, might not parse according to the rules, might prevent the compiler from turning his routine into an “object file,” a little file full of ones and zeros, ready to be linked up with other object files to create the executable program. He wasn’t getting fatal errors — no, not on this pass. There was nothing yet that caused the compiler to issue the awful message that began, “Fatal error,” and then, abruptly, stop. But such fatalities had already befallen him many times this morning, how many times, he’d lost track — twenty, fifty, a hundred? On each occasion, he had fixed whatever little thing wasn’t legal, didn’t parse, prevented his code from becoming machine-readable bits; and then he ran the compiler again.

Warning. Warning. Warning. Fatal error. Stop.

Fix the little thing in the code that wasn’t legal. Run the compiler again.

Warning. Warning. Fatal error. Stop.

Fix the next little thing.

Warning. Warning.

“It’ll compile this time,” was the only thought Ethan Levin kept steadily in mind, over and over, on that morning of March 5th, 1984. Even the phone had to go on ringing — once, twice, three times — until it reached him, three rings to get inside his window of attention so tuned to the nervous refresh rate of the screen: Warning. Warning.

“What! Are you still there?” said the voice on the phone. “You’re supposed to be here!”

He sat confused for a moment. Yes, he knew the voice was Joanna’s, but the words “there” and “here”: what exactly did they mean? Then, all at once, his attention snapped into focus: it was Joanna, he was supposed to take her to the airport, and he was late.

“I’m leaving!” he said.

“I mean now. Are you leaving now?”

“I’m leaving, I’m leaving,” he said again, but vacantly, automatically, because despite himself, his eyes had been drawn back to the screen, to the irregular pulse of the messages as they appeared: Warning. Warning.

“Hello? Are you there?”

“Yeah, yeah. I’m here,” he said, just as the compiler suddenly displayed the message, “Fatal error: MAXWINSIZE not defined,” and came to a stop.

“Shit!” Ethan Levin muttered under his breath.

“Ethan! You’re compiling! I know it!”

“Yeah, yeah, sorry,” he said to Joanna McCarthy, who, as his girlfriend of four years, knew all too well the sort of exclamations he made when he was programming and compiling. “Sorry,” he repeated, but again automatically, because — though he knew better than to do this now — his mind immediately began ranging over the places where MAXWINSIZE should have been defined. On one side of his attention was Joanna, the month-long trip to India she was taking with Paul Ostrick, husband of her best friend Marsha Ostrick, and the promise Ethan had made to take them to the airport — and be on time! he swore! But on the other was this sudden and unexpected problem of MAXWINSIZE, this branching trail of questions that led off in many directions, curious and puzzling, down which his mind involuntarily started traveling …

“It’s an airplane, Ethan! It’s not going to wait for a compile!”

“Shit! Yes! I’m leaving now.”

“That’s like now now, right? Not like a one-more-compile now?”

“Now now,” he repeated, as much to himself as to Joanna. “Now now.”

Still, even after he’d stood up and grabbed his jacket from the back of his chair, the face of the screen drew him back. He sat down again, reread the messages on the monitor, typed a command to the system that set it searching through the entire code library for all occurrences of MAXWINSIZE. Yes, much better now. The system would tell him where the problem was. Then, tomorrow, he’d fix it.

- – - – - – - – - – - -

Days open: 32

Debugging: what an odd word. As if “bugging” were the job of putting in bugs, and debugging the task of removing them. But no. The job of putting in bugs is called programming. A programmer writes some code and inevitably makes the mistakes that result in the malfunctions called bugs. Then, for some period of time, normally longer than the time it takes to design and write the code in the first place, the programmer tries to remove the mistakes. One by one: find a bug, fix it. Bug: supposedly named for an actual moth that found its way into an early computer, an insect invader attracted to the light of glowing vacuum tubes, a moth that flapped about in the circuitry and brought down a machine. But the term surely has an older, deeper origin. Fly in the ointment, shoo fly, bug-infested, bug-ridden, buggin’ out, don’t bug me — the whole human uneasiness with the vast, separate branch of evolution that produced the teeming creatures who outnumber us, plague us, and will likely survive our disappearance from the earth. Their mindless success humbles us. A parallel universe without reason. From the Welsh: a hobgoblin, a specter.

Ethan Levin had never encountered a bug that was anything like a specter. In his twelve years as a programmer, he had come to understand that the process of programming was more or less equivalent to the process of debugging. Bugs were inevitable, everywhere, part of the job. So it was that, in the early afternoon of April 6, 1984, despite the fact that he had declared UI-1017 to be “fixed” and it had now certainly reappeared as not fixed, he reached over for the bug report with a sense of utter normalcy. And more: with the certainty that, while there would always be bugs in general, the cause of this particular bug would surely be found. For a bug always begins its life that way: as a creature of the programmer. It was a mistake, yes, a miscue, a slip of the mind; but the programmer’s mistake, his slip, of his mind. If Ethan had taken any particular notice of what was going through his mind that day, he would have heard his usual internal conversation in which he told himself that this was merely the one-thousand seventeenth bug in the user interface; one-thousand sixteen of which had already been fixed; some untold number yet to come, each in turn to be fixed in good order.

He reached for the bug report and reread the summary. And immediately the underlying code came to him — the pyramid of routines, code calling code, all finally resolving down to the operating system and the routines that managed the mouse, the disk, the peripherals, the network. He decided that the problem had to be in the code that supported the screens — the routines responsible for the menus and the mouse, most of it his own. Funny. That code had been out there for a long time, working. So what had changed? Code works for months and then suddenly stops working: something must have changed.

The answer came to him in a huge, head-clearing Of course! The cause was simple, ridiculously simple. He’d been working on those routines that night he was late to dinner and rushed home. He must have closed up everything too quickly, put the wrong versions back into the library. He could have confirmed this theory; he might have looked at the current version in the source-code control system. But his certainty swept him away. The bug had come back right then, on the very next day. Of course. All he had to do now was rebuild the user-interface library. Then retest the two screens. Which he did: Perfect. Working. Fixed.

Some part of Ethan’s mind knew that not encountering the bug right then was no assurance that the bug was indeed fixed. That tester could never reproduce the bug, and he himself couldn’t make it appear at will. It came and went, might come back again. And he knew that rebuilding a library was superstitious programmer behavior. Everyone did it. Have a problem you can’t find? Recompile and relink the code, and hope the problem goes away. Like a ballplayer in a slump who crosses himself before stepping into the batter’s box, it was a ritualized compulsion, a set of things you do over and over, things that may not work but you never know.

But he pushed these thoughts away. Ethan was still in the first phase of debugging. He may have accepted the second report of UI-1017, since he’d had no choice, but deep inside him he was still convinced there was no bug. It was user error, something wrong in the network, a glitch on the line, an out-of-date library, something else, but not a bug in his code. The stage every programmer with an unsolved bug clings to as long as possible: denial.

Days open: 91

The bug hid from the debugger. Ethan went back to his office, his debugger, his bug, but the system never crashed while the debugger was watching it. A quantum effect? Something in UI-1017 that was like an electron whose path is altered by the presence of an observer?

Ethan was certain — at each step — that the next one would bring on the crash. I’ll put in a breakpoint here, he thought; the program will pause; I’ll step to a line of code here, and certainly there it will be: the crash, the exact point where some mislogic had wound its way through the layers of code, finally percolating into functional absurdity. Some pointer would be NULL when it should have the value of an address in memory. Some Boolean variable would evaluate to FALSE when it should be TRUE. Some return code would show an error condition that was not checked by the program. And then all he had to do was think his way back through the layers, discover why it was NULL, FALSE, unchecked.

Step, he typed.

Line of code, the debugger answered.

Step, he typed.

Line of code, the debugger answered.

He ran his hands through his hair. Stared at the screen. Entered a new breakpoint.

Step.

Line of code.

Step.

The afternoon wore away, then the evening. His two officemates left, one then the other. The windows faded to black; the lights blinked off in office after office across the floor. Step, step, step, he went, walking through the code one programming statement at a time. It must be here, he thought. No, here. It will crash the next time. Okay, then the next time.

There was a roar at the door. The lights flashed on.

“Lo siento,” said the office cleaner.

She ignored him, he her. He lifted his feet, she vacuumed around him, turned off the lights, and moved on.

The moment the room went dark again, Ethan felt a surge of panic. What time was it?

Eleven. He should call Joanna.

The phone rang and rang. No answer. He dialed again. Again no answer. Where was she? Where was she?

Better fix that bug, his boss had said. The company president is acting like he never saw a bug before. The VCs are watching. Tomorrow he was supposed to meet with Harry about the schedule. He could not stop and simply leave a note for himself. No, the only note he could leave himself could be the bug report itself, with its message to the testers saying, “Fixed.”

Step, step, step.

Some part of him knew that he should get away from the debugger. He should get away from the machine, stop and think on a yellow pad, a white board. He wasn’t making headway this way. He kept beating against the same certainties — here, else here, else here. Writing and sketching might break his thinking patterns, force him into other channels. But there was something seductive about the debugger: the way it answered him, tirelessly, consistently. Such a tight loop: Step, he said. Line of code, it answered. Step, line of code; step, line of code. It was like the compulsion of playing solitaire: simple, repetitive, working toward a goal that was sure to be attained in just one more hand, just one more, and then one more again.

And so the paradox: The more the debugger remained the tireless binary companion it was designed to be — answering, answering, answering without hesitation or effort late into the night — the more exhausted and hesitant the human, Ethan Levin, found himself to be. He was sinking to the debugger’s level. Thinking like it. Asking only the questions it could answer. All the while he suffered what the debugger did not have to endure: the pains of the body, the tingling wrists and fingers, the stiffness in the neck, the aching back, the numb legs. And worse, the messy wet chemistry of the emotions, the waves of anxiety that washed across him, and then, without warning, the sudden electric spikes of panic.

Internet voting is surely coming. Though online ballots cannot be made secure, though the problems of voter authentication and privacy will remain unsolvable, I suspect we’ll go ahead and do it anyway. Click here for the leader of the free world. It will be too easy, too convenient, too familiar to resist. After we have put our intimate secrets and credit card numbers online, what can prevent us from putting our elections there as well?

Knowing that, I’m taking a moment to reconsider the value of the polling place, of voting as a public, civic ritual. I have the sense I’m doing what newspapers do with the obituaries of important persons: composing an elegy while the people are still living, gathering up the valuable stuff of their lives, so that when someone dies, we can see right away what we’ve lost.

- – - – - – - – - – - -

The act of voting, to put it in computing terms, is a question of user interface. What sort of physical representation do we want to give to this most central act of citizenship? Here on one side is the browser window, looking in essence like every other Web page — the usual form to fill out, the inevitable button at the bottom which everyone has somehow decided should be labeled “Submit.” And on the other is the polling place: that slightly ramshackle affair of rec rooms and church basements and garages, where poll workers, usually retired people, run a gnarled hand down the voter roll looking for your name; that place of large purposes and small human fumblings.

At 8:30 a.m. at my polling place, there’s no sign outside yet, only a 1-by-1.5-inch yellow sticky on the door that says “VOTE HERE –>.” William Larry Noles, a retired man who says he works at the polls for “something to do,” apologizes as he brings out the official sign. “Everything’s a little late,” he says.

Inside, about 10 people are already voting. Oddly, about half of them have chosen not to stand up at the rickety little “booths” with privacy barriers, but to sit at a long table in the center of the room, where they look like students at a library, frowning with concentration at the long ballot in front of them. Six of us wait in line to check in. When I get to the desk, in a minute or two, the poll workers have trouble finding me on the rolls. The problem seems to be with the way the apartment numbers are listed at my address, C307 sorting in a separate sequence from C-306 and C-308. Eventually, the poll worker, Cecilia Bulosan, finds me and I get my ballot. Cecilia is a Filipina who seems to be in her 60s; she says she’s getting paid $82 for the day of poll working plus $25 for attending a seminar beforehand. Working nearby is Fred Silva, whom she describes — shyly, dropping her voice — as her “boyfriend.” Fred, wearing a baseball cap that says, “I’m Fantastic in Dark Places,” is standing by the Optech IIP Eagle tallying machine (“Proven solutions for the world of elections,” says the machine’s label), feeding in completed ballots. The machine keeps complaining. “Unvoted” is the message the machine keeps giving. “Blank ballot.”

Dealing with all the problems — voters missing from the rolls, people voting outside of their precincts, the ever-complaining Optech machine — is Peggy Baslow, the inspector at this precinct. She is a young woman in black-rimmed glasses with unflagging energy. She is interrupted constantly but never becomes short-tempered. “Here is what you do,” she says to the young man who is at the wrong polling place, showing him how to vote here anyway. “I’m coming,” she says to Fred every time the Optech balks. “I’m sorry,” she keeps saying to everyone, for the wait, for the confusion, for whatever little difficulties are happening now. And it’s clear she is sorry. She is competent and cares that things go well, and so no one seems to mind that the process is creaking along, just barely under control. A man near the end of the line looks around and jokes with the woman behind him. There’s a hot tub just outside the rec room, where a bald guy sits steaming in a cloud of water vapor, which both of them for some reason find very funny.

As the day goes on, Peggy, Cecilia, Fred and William help about 400 people to vote, and by the time I come back to see them, at 6:30 p.m., the rec room has become a little airless and sweaty. Seventeen people are now working on their ballots. They stand at the booths, sit at the library table, sprawl on the leatherette sofas. Fred has taken off his hat, but Peggy Baslow remains energetic and courteous. She’s still calling voters “Sir” and “Ma’am,” still saying “Thanks for voting,” as people hand in their ballots, still dealing with the hundred little complexities and anomalies of people’s lives: the one who moved from Treasure Island and doesn’t know where to vote, the person whose address is wrong, the voter who crossed out an entry on the ballot and now needs to start a fresh one.

As I watch her, it comes to me that Peggy Baslow is the perfect human interface to a democratic republic. I like the fact that the quality of the voting process has depended on her — that the experience of voting should be variable, resting on the energies of a particular individual, even if this means that another polling place might be having a less-happy voting experience. It seems somehow right that the act of electing an individual to be president of the United States should also involve the distinctions between one person and another at the polling place, that individual abilities should matter.

I like the little semi-competencies of human beings, I realize. Governance, after all, is a messy business, a world of demi-solutions and compromise, where ideals are tarnished regularly. Voting, then, should perhaps offer up the true face of government: something worked out by human beings in an energetic muddle, a creaky, lumpy process that somehow deals with the hundred little peculiarities of the people involved in it.

As I leave, I think about how the polling place is a homespun affair. Looking around at the rec room, with its humming Coke machine at the doorway, it’s impossible to feel that the government is something “out there” — a slick machine into which your ballot disappears. You can see that government is something organized — and disorganized — by human beings who mostly try to do their best. Down the block from the polling place is a restaurant, where I run into a neighbor at the bar. She has just come from voting, and we talk about the polling place, the people we saw there, how it went. My neighbor describes it all with some affection; the process of voting, she says, was “very dear.”

- – - – - – - – - – - -

I don’t think anybody called the world’s first officially binding online election “dear.” It was the Arizona Democratic Party primary, held on the Web between March 7 and 10, 2000. Joe Mohan, CEO of election.com, the company that supplied the software, didn’t make a case for the sweetness of his efforts, having grander, more sweeping things to say about this online first. “Online voting will revolutionize the election process,” he said, calling it an “embrace of the future.”

For a while after the election, a demonstration of the Arizona election ran on the company’s Web site. And so, hoping for a taste of the future I would someday have to embrace, I tried the demo, an election that immediately presented itself in a series of pretty red, white and blue forms.

There were no confusions or fumblings at this polling place. Signing in, the process that would later introduce me to Cecilia Bulosan, consisted of a few keystrokes and a click. Then came the ballot: four big blue buttons, the candidates’ names written on them in white.

I went click.

“You are about to cast your vote for Al Gore,” said a little pop-up dialog box. “Click on OK to submit your vote. Click on Cancel to choose another candidate.”

OK.

Then off the data went to a server somewhere, out there into the ether — far away from me or right next door, I had no way of knowing. The vote went into “the system”: opaque, closed, proprietary software. There was no way to see who else was voting, no neighbors to run into at a bar. No ballots or voters or poll workers: between me and my chosen candidate, nothing and no one. Democracy as magic, unpeopled, for the benefit of the people.

This solitariness seemed to please the election’s client, Arizona Democratic Party chairman Mark Fleisher. “The sizzle is the vote at home in your pajamas at 10 o’clock at night,” he enthused to USA Today after the election. It was as if voting should somehow be like shopping for an online plane ticket — best if done at home, alone, more fun if performed in a state of dishabille.

Yet that solitariness disturbed me. The sense of sitting all alone was somehow dispiriting. I did not want voting to be this disembodied, disintermediated act. The act of voting — deciding whom you’d like to elect, filling out the ballot — may indeed be the most constitutionally protected, private, secret act a citizen can perform in a democratic society. But it also takes place in a supremely social, civic context. What online voting had eliminated was precisely that tension: between personal liberty and social obligation, between the private, secret choice and its social, civic effect.

It had also turned voting into an act indistinguishable from any other online interaction. Experience is visual and physical; what we think comes to us embodied, enacted. And what my eyes and body had just offered me was an experience more like shopping than voting. Immediately after voting, I turned to ordering groceries from Webvan — forms, buttons, clicks, hardly a change in my perceptional field.

This is the image projected by the Internet voting page: an experience like shopping on the Net, picking out exactly what you want from the offerings of the world. The perfect camera or computer or plane flight — exactly what you’re looking for. But democracy is not about getting exactly what you want; it’s about the attempt to resolve differences among people when the desires of one may preclude the wants of another. It’s a sorting out of desires, leaving some inevitably unmet, even when the process works very well. Given this, I fear the visual trick of the Web page: the expectation it creates of satisfactions guaranteed, of the citizen as customer.

What most disturbed me about voting online, however, was its efficiency. This may sound odd, since speed is a good thing in a computer system. Networks have to be fast. And the Web voting page gives the illusion of cleanliness, efficiency. It projects the idea, by its very visual representation, that government, like trains perhaps, should be made to run on time.

But efficiency is a machine value, not necessarily a human one. The practice of politics is more about persuasion than it is about functioning; and persuasion is, by definition, a maddening, heat-wasting activity. In a relatively democratic system like our own, it’s perhaps better if change happens slowly, after much debate. As pointed out to me by the computer scientist David Rosenthal, in governance “slowness is a feature, not a bug.”

As I write this, for instance, in the evening of Wednesday, Nov. 8, we still don’t know who will be the next president of the United States. Florida will have to recount its ballots — those bulky, slow pieces of paper — not to mention all those absentee votes still flying or sailing or being trucked to Florida by the quaint antique practice of snail mail. If we’d voted on the Web, we’d have banished all this awful inefficiency. Click, off to the server, counted. Barring a major hack or cascading network failure (computer systems can fail spectacularly), it would all be over.

And we might be sitting stunned at the outcome: a president elected without winning the popular vote, perhaps, an election turned on a few hundred votes in a couple of precincts in Florida, a race so close that we as a nation seemed not to have had any preference at all.

But we’re spared; all that slow paper gives us time to think. Anyone turning on the radio or going to a Web page can learn about the Electoral College, how it functions, when it was set up and why. We get history lessons: the past presidents who came to office without clear popular mandates, how they governed and how the republic survived. In the achingly long days — days, forgodsakes, in this age of nanoseconds — chat rooms will be full, e-mail flames will fly, friends will call one another, neighbors who rarely talk will stop and talk on the street because this election is happening to everyone. A nation will look into its political process while it waits. And by the time the election results are known, we’ll be prepared.

Hurrah for slow, I think, as the chatter continues on the television. Waiting is good. Long live paper and polling places, and events unfolding in the fullness of time.

At any rate, this didn’t stop Foner. He had a programmer’s idea of how things get done in the world: Forget about the government; don’t form a committee. Just write up a short proposal, give your idea a silly hacker-ish sort of name (even he admitted that the name he chose, “Smoosh,” was somewhat unfortunate), talk about it to some very smart people, get a small group of them interested, then just start hacking out some code.

John Gilmore, a founder of the Electronic Frontier Foundation and self-described libertarian, was at the workshop, and with terrible succinctness he laid out the thinking behind Foner’s vision of the programmer-created world. Gilmore was opposed to too many people getting involved in whatever Foner is going to do. “Almost everything that works on the Net grew out of tiny groups of people working in isolation,” he said.

Meanwhile, as Foner was talking about “how to prototype something new,” there was event No. 2: The Canadian Parliament was passing Bill C-6, a data protection act like the European Union’s Data Directive — leaving the United States as the sole highly industrialized nation without legal data-privacy protections.

Evidently, the process leading to the passage of the C-6 was nothing like the “tiny groups working in isolation” that John Gilmore had described just a few minutes before. According to Stephanie Perrin, who worked with the Canadian Department of Commerce and Industry for 20 years and who took part in the drafting of the bill, it had involved hundreds of people. It required concessions on all sides. The resulting law is not perfect. “It was a long and difficult process,” she said, “where everyone fought.”

These two events — the programmers workshop and the passing of a federal data-privacy law — are like the ends of a rope in a heatedly fought game of tug-of-war, a game that has been battled at CPF over the course of the conference’s 10-year existence.

On one side are the geeks, nerds, crypto-anarchists, libertarians and cypherpunks — mistrustful of government, suspicious of all attempts at regulation, believers in the ability of technology, in and of itself, to solve society’s ills (maybe with a little marginally legal hacking on the side, just to keep the political pot boiling). Austin Hill, president of Zero-Knowledge, opened the conference like a true techno-believer, quoting John Gilmore as saying, “I want to guarantee [privacy] with physics and mathematics, not with laws.”

Opposing the technologists are the believers in law above all else: the think-tank and activist lawyers; the privacy commissioners in their well-cut European suits; the pragmatists advocating commissions and studies and meetings — participants in the rough-and-tumble of political life, with all its confusions and compromises and imperfect results.

In the past, the techno-believers ruled CFP. The programmers’ vision of creation — the lone geniuses — prevailed over the data-privacy “bureaucrats” — so hard to listen to, after all, with their thick foreign accents and their tedious, confusing laws.

But something different happened this year. The flag in the middle of the tug-of-war rope moved. Two well-known technologists, known for their belief in working code and skepticism about the workings of law, stepped across the divide, moving, maybe despite themselves, toward a recognition of social and political realities. Two others, whose views have been more balanced, questioned libertarianism — the limitations of a technocentric approach to the complicated questions of privacy and freedom. It was as if some tipping point had been reached, in which a critical mass of people involved in technology had suddenly looked up and found themselves to be older, grown-up, and in need of social supports — grown-up like the Net itself.

The first famous technologist over the line — albeit tippy-toeing — is Phil Zimmermann, creator of PGP (Pretty Good Privacy) encryption software, techno-hero, defier of the government when it tried to declare encryption a “weapon” and Zimmermann a felon for “exporting” it.

His moment comes during the discussion following the dinner speech on Wednesday night. Neal Stephenson, a writer with a cultlike following among the technologically minded and author of the classic “Snowcrash,” has given an over-long, hugely digressive — and brilliant — speech. After many, many turns and a deep stack of points and stories, Stephenson gets around to saying that the best defense for one’s privacy and personal integrity turns out to be not cryptography but, what do you know, “social structures.” He is not explicit about the exact nature of these structures, but from the slides that follow, we get a sense of every sort of social relationship from neighborly friendliness to political parties. The slides show drawings of small circles representing areas of social trust. The circles widen and merge, to create a field of autonomy, a trusted space.

Stephenson is making a point about code: Without a sociopolitical context, cryptography is not going to protect you. He singles out PGP for criticism, saying that relying on the encryption scheme is like trying to protect your house with a fence consisting of a single, very tall picket. A slide shows the lone picket rising into the sky, a bird considering it with bulging eyes.

After the speech, Zimmermann puts up his hand, and of course Stephenson calls on him. It’s clear Zimmermann has “gotten” the speech. He doesn’t go so far as to endorse anything like “social structures,” communities of trust, neighborhoods of understanding — no, of course not. Zimmermann has been staunchly against laws, rules, regulations: anything that could be considered a form of social coercion. But he does admit that perhaps code is not enough, that he never intended encryption, by itself, to work. “I never meant PGP to be the defense of a lone libertarian,” he says.

It is a huge admission, in its way, from a programmer who has
championed code as a way to save us. But if this libertarian is not “lone,” he is with some other libertarians, presumably. And what are these more-than-one libertarians doing? Organizing? Petitioning their government? Creating zones of social trust? Zimmermann is a man who defines the word “loner”; he has a tight manner; one doesn’t imagine he’s spent a lot of time working on his empathy or inner doubts. He probably doesn’t even let himself realize the implications of what he’s just said.

“Let the record show,” Stephenson says carefully in reply, “I never said the word ‘libertarian.’”

- – - – - – - – - – - – - – - – - – - – -

Tim Berners-Lee, creator of the World Wide Web and director of the World Wide Web Consortium, will indeed say the word “libertarian.” He will say it on Thursday night, when he is the recipient of an EFF Pioneer Award, given every year “to honor significant contributions to the advancement of rights and responsibilities in the Information Society.”

Berners-Lee can’t be there, but he has sent a videotape with his thanks. He feels honored, is genuinely grateful.

And then he looks less happy. Berners-Lee starts thinking about what has happened to the Web since he dreamed it up: e-commerce, big corporations, money. “Libertarians are used to fighting the government,” he says, “and not corporations …”

This must be very difficult for him to say. For the libertarians in the audience to hear that business and free markets may not be the bringers of unalloyed good … To imagine that a business is something to be fought, not respected … No. Better to go off, leave the thought, don’t say anything more.

But he can’t somehow. Another unhappy thought comes: “I know we don’t like regulation where we can avoid it, but …”

And there he surely must stop. Bad enough to imagine fighting a corporation, but to do it with regulations? Regulations, meaning laws, meaning government? He has crossed into libertarian anathema.

Why has this techno-hero raised the specter of libertarianism? Theoretically, Berners-Lee personifies the “lone genius” technology ideal: While working as a consultant at CERN, he went off by himself, just for his own amusement, and coded up what we now call hypertext. Theoretically, he has every right to believe that somebody else will go off alone, just for his or her own amusement, and solve the problem of corporate control of the Web.

But it seems he has recognized a changed world, where neither he nor some other programmer can do it alone. “We have to make sure that when people go to the Internet, they get the Internet,” he says, meaning the real Net, the true one, the original — whatever that might mean to him, or us. Somehow, even if it means laws and rules and governments, we must find our way back to this idyll. We must route around the new bad corporate Net, or create a superset of it, or an alternative. Or something.

Berners-Lee was speaking unpopular truths to the CFP crowd, but his outspokenness is nothing compared to what is about to happen. The next Pioneer award is to go not to an old programmer or to a lawyer at a think tank, but to … “librarians everywhere.” Can we be hearing correctly? Did they say librarians and not libertarians? But it’s true: librarians. It is an unprecedented award, the first to a group that can’t be associated with at least a few specific individuals. And in the face of this — this amazement, this recognition of the great unseen and unsung core of mostly women — the fourth of our techno-heroes will find himself to be, in his startled heart, a lover of civil servants.

Whitfield Diffie bounds to the platform. Diffie is a crypto-king, the discoverer, with Martin Hellman, of public-key encryption, cornerstone of the libertarian worldview in which technology
protects the individual from the reach of goverment. He stands now before the audience with his neat gray beard, shoulder-length blond hair and sudden uncontained enthusiasm. “Librarians!” he exclaims. “I’m thrilled with this award.”

He goes on to say he was not involved in the judging; this is the first moment he has learned of it. And now that he thinks of it, those wonderful librarians of his childhood, the ones who helped him when he was working on his dissertation — yes! Librarians!

“I wouldn’t have thought to give this award,” he declaims in the full throes of the convert’s confession. “Therefore it comes as a revelation.”

All those invisible, dedicated civil servants. Mostly working for government. In public libraries. Paid for by taxes. Diffie stands there with arms out. He is truly, naively, nakedly, unabashedly amazed to consider it. The whole libertarian edifice crumbles as he looks at it. Revelation.

- – - – - – - – - – - – - – - – - – - – -

But this is more than a startled, unguarded moment. The next day, in a speech he gives at lunch, Diffie reveals the depth of his conversion.

“Everyone stop eating,” he begins, and indeed we should, for what we are about to hear is akin to the more common story of a middle-aged person, communist in his youth, who grows more conservative as he grows older, renounces his youthful beliefs — except we will hear it in reverse, right to left.

He signals it all right away. “Crypto was a security technique that didn’t require trusting anyone else,” Diffie says. “Now it turns out you have to trust other people.” He was younger, he seems to say, he had ideas, he was wrong. “I had a very mathematical and very inapplicable idea about authentication.” And there it is: an implicit rejection of the Gilmore-ian ideal of trust in physics and mathematics. Like Stephenson, like the reluctant Zimmermann, like the unhappy Berners-Lee, the father of public key encryption has come to the conclusion that software may reduce the amount of trust you need in human beings, but as one moves about in the world, the sense of security, privacy and autonomy turns out to be “a function of social structures,” as Diffie says.

So far, Diffie has gone from being a techno-libertarian to a standard-issue social democrat — a remarkable move, if not a remarkable place to wind up. But he is not done.

What has sparked his conversion, it seems, is the recentralization of computing: how we have moved from the centrally controlled timesharing system, to the autonomous powerful desktop PC, to the networked computer, and thence — sidetracked through the network computer and the “thin client” — somehow back to the dumb terminal. He foresees how knowledge workers will lose their autonomy by being forced to use such slavish machines; how they can become mere objects of surveillance by the companies they work for, as a result of “corporate imperialism over its workers.”

Is there something wrong with the microphone? Is he talking about imperialism? Yes, and on he goes, ever leftward. He can foresee a day when workers, doing their jobs from the “convenience” of their homes, are forced to be subject to “spot inspections” by their employers, a time when the home is effectively turned into an occupied zone where corporations exercise power over their property.

What shall we desperate knowledge workers do? Organize! We need “the rise of labor again,” says Diffie, former crypto-believer. “We need to tighten up the relationships among knowledge workers,” he says, “and bargain as a whole.”

I can’t believe what I am hearing.

- – - – - – - – - – - – - – - – - – - – -

The conference ends with a session on “diversity” — and again, one is startled to find this at CFP, former home ground of crypto-anarchists and techno-libertarians. On the podium is Greg Bishop of TheStreet.com, one of only two African-Americans on the entire conference program, perhaps the only one attending CFP. He is telling us how the black people he knows are amazed he uses a computer — they believe that once you plug it in, the government knows everything about you. The audience goes on to question the homogeneity of the conference itself — why there are so few young people, blacks and women in attendance, and indeed in the leadership of the technological world. The culture wars have come to CFP.

And why not? The Internet, with its vast public acceptance, letting people who have never even seen a piece of code do everything from buy a car to search for lovers, can hardly be considered a purely technological system anymore. The Net has become a social space, and it is perhaps right that the practices of programmers — the small group in isolation — no longer pertain. We’ve come to the messy part that very senior programmers get to avoid: the part where the system has moved beyond the “new” and “dreamed-up” stage. Where it is successful — that is, it has users, millions of them, with all their conflicting needs and desires, and only the messy, horrid, compromised, wonderful, exhausting processes of democratic social discourse can sort them all out.

After the conference is all over, it’s fun to sit with Bruce Umbaugh, philosopher and member of the CFP organizing committee, and imagine the sort of happy chaos that can happen at the event next year. We’ll invite the UAW! We’ll invite the Boeing engineers, knowledge workers who have organized themselves for the first time — and won! There’ll be online dykes and gangsta Napster rappers. There’ll be kids and students and mothers and just about anything else you can think of. And why not? When we said the Internet represented a “revolution,” we meant it — didn’t we?

Over time, the only representation of the original knowledge becomes the code itself, which by now is something we can run but not exactly understand. It has become a process, something we can operate but no longer rethink deeply. Even if you have the source code in front of you, there are limits to what a human reader can absorb from thousands of lines of text designed primarily to function, not to convey meaning. When knowledge passes into code, it changes state; like water turned to ice, it becomes a new thing, with new properties. We use it; but in a human sense we no longer know it.

The Year 2000 problem is an example on a vast scale of knowledge disappearing into code. And the soon-to-fail national air-traffic control system is but one stark instance of how computerized expertise can be lost. In March, the New York Times reported that IBM had told the Federal Aviation Administration that, come the millennium, the existing system would stop functioning reliably. IBM’s advice was to completely replace the system because, they said, there was “no one left who understands the inner workings of the host computer.”

No one left who understands. Air-traffic control systems, bookkeeping, drafting, circuit design, spelling, differential equations, assembly lines, ordering systems, network object communications, rocket launchers, atom-bomb silos, electric generators, operating systems, fuel injectors, CAT scans, air conditioners — an exploding list of subjects, objects and processes rushing into code, which eventually will be left running without anyone left who understands them. A world full of things like mainframe computers, which we can use or throw away, with little choice in between. A world floating atop a sea of programs we’ve come to rely on but no longer truly understand or control. Code and forget; code and forget: programming as a collective exercise in incremental forgetting.

Every visual programming tool, every wizard, says to the programmer: No need for you to know this. What reassures the programmer — what lulls an otherwise intelligent, knowledge-seeking individual into giving up the desire to know — is the suggestion that the wizard is only taking care of things that are repetitive or boring. These are only tedious and mundane tasks, says the wizard, from which I will free you for better things. Why reinvent the wheel? Why should anyone ever again write code to put up a window or a menu? Use me and you will be more productive.

Productivity has always been the justification for the prepackaging of programming knowledge. But it is worth asking about the sort of productivity gains that come from the simplifications of click-and-drag. I once worked on a project in which a software product originally written for UNIX was being redesigned and implemented on Windows NT. Most of the programming team consisted of programmers who had great facility with Windows, Microsoft Visual C++ and the Foundation Classes. In no time at all, it seemed, they had generated many screenfuls of windows and toolbars and dialogs, all with connections to networks and data sources, thousands and thousands of lines of code. But when the inevitable difficulties of debugging came, they seemed at sea. In the face of the usual weird and unexplainable outcomes, they stood a bit agog. It was left to the UNIX-trained programmers to fix things. The UNIX team members were accustomed to having to know. Their view of programming as language-as-text gave them the patience to look slowly through the code. In the end, the overall “productivity” of the system, the fact that it came into being at all, was the handiwork not of tools that sought to make programming seem easy, but the work of engineers who had no fear of “hard.”

And as prebuilt components accomplish larger and larger tasks, it is no longer only a question of putting up a window or a text box, but of an entire technical viewpoint encapsulated in a tool or component. No matter if, like Microsoft’s definition of a software object, that viewpoint is haphazardly designed, verbose, buggy. The tool makes it look clean; the wizard hides bad engineering as well as complexity.

In the pretty, visual programming world, both the vendor and programmer can get lazy. The vendor doesn’t have to work as hard at producing and committing itself to well-designed programming interfaces. And the programmer can stop thinking about the fundamentals of the system. We programmers can lay back and inherit the vendor’s assumptions. We accept the structure of the universe implicit in the tool. We become dependent on the vendor. We let knowledge about difficulty and complexity come to reside not in us, but in the program we use to write programs.

No wizard can possibly banish all the difficulties, of course. Programming is still a tinkery art. The technical environment has become very complex — we expect bits of programs running anywhere to communicate with bits of programs running anywhere else — and it is impossible for any one individual to have deep and detailed knowledge about every niche. So a certain degree of specialization has always been needed. A certain amount of complexity-hiding is useful and inevitable.

Yet, when we allow complexity to be hidden and handled for us, we should at least notice what we’re giving up. We risk becoming users of components, handlers of black boxes that don’t open or don’t seem worth opening. We risk becoming like auto mechanics: people who can’t really fix things, who can only swap components. It’s possible to let technology absorb what we know and then re-express it in intricate mechanisms — parts and circuit boards and software objects — mechanisms we can use but do not understand in crucial ways. This not-knowing is fine while everything works as we expected. But when something breaks or goes wrong or needs fundamental change, what will we do but stand a bit helpless in the face of our own creations?

Linux won’t recognize my CD-ROM drive. I’m using what should be the right boot kernel, it’s supposed to handle CD-ROMs like mine, but no: The operating system doesn’t see anything at all on /dev/hdc. I try various arcane commands to the boot loader: still nothing. Finally I’m driven back to the HOW-TO FAQs and realize I should have started there. In just a few minutes, I find a FAQ that describes my problem in thorough and knowledgeable detail. Don’t let anyone ever say that Linux is an unsupported operating system. Out there is a global militia of fearless engineers posting helpful information on the Internet: Linux is the best supported operating system in the world.

The problem is the way the CD-ROM is wired, and as I reach for the screwdriver and take the cover off the machine, I realize that this is exactly what I came for: to take off the covers. And this, I think, is what is driving so many engineers to Linux: to get their hands on the system again.

Now that I know that the CD-ROM drive should be attached as a master device on the secondary IDE connector of my orphaned motherboard — now that I know this machine to the metal — it occurs to me that Linux is a reaction to Microsoft’s consumerization of the computer, to its cutesying and dumbing-down and bulletproofing behind dialog boxes. That Linux represents a desire to get back to UNIX before it was Hewlett-Packard’s HP-UX or Sun’s Solaris or IBM’s AIX — knowledge now owned by a corporation, released in unreadable binary form, so easy to install, so hard to uninstall. That this sudden movement to freeware and open source is our desire to revisit the idea that a professional engineer can and should be able to do the one thing that is most basic to our work: examine the source code, the actual program, the real and unvarnished representation of the system. I exaggerate only a little if I say that it is a reassertion of our dignity as humans working with mere machine; a return, quite literally, to the source.

In an ideal world, I would not have to choose between the extreme polarities of dialog box and source code. My dream system interface would allow me to start hesitantly, unschooled. Then, as I used the facility that distinguishes me from the machine — the still-mysterious capacity to learn, the ability to do something the second time in a way quite different from the first — I could descend a level to a smarter, quicker kind of “talk.” I would want the interface to scale with me, to follow me as my interest deepened or waned. Down, I would say, and it would let me get my way, however stupid or incomprehensible this seemed to it, a mere program. Up, I could say, so I could try something new or forgotten or lost just now in a moment of my being human, nonlinear, unpredictable.

Once my installation of Linux was working, I felt myself qualified, as a bona fide Linux user, to attend a meeting of the Silicon Valley Linux User’s Group. Linus Torvalds, author of the Linux kernel and local godhead, was scheduled to speak. The meeting was to be in a building in the sprawling campus of Cisco Systems. I was early; I took a seat in a nearly empty room that held exactly 200 chairs. By the time Torvalds arrived half an hour later, more than twice that many people had crowded in.

Torvalds is a witty and engaging speaker, but it was not his clever jokes that held the audience; he did not cheerlead or sell or sloganize. What he did was a sort of engineering design review. Immediately he made it clear that he wanted to talk about the problem he was just then working on: a symmetrical multiprocessing kernel for Linux. For an hour and a half, the audience was rapt as he outlined the trade-offs that go into writing an operating system that runs on multiple processors: better isolation between processes vs. performance; how many locks would be a good number, not too many to degrade response, not so few to risk one program stepping on the memory area of another; what speed of processor should you test on, since faster processors would tend to minimize lock contention; and so on through the many countervailing and contradictory demands on the operating system, all valid, no one solution addressing all.

An immense calm settled over the room. We were reminded that software engineering was not about right and wrong but only better and worse, solutions that solved some problems while ignoring or exacerbating others. That the machine that all the world seems to want to see as possessing some supreme power and intelligence was indeed intelligent, but only as we humans are: full of hedge and error, brilliance and backtrack and compromise. That we, each of us, could participate in this collaborative endeavor of creating the machine, to the extent we could, and to the extent we wished.

The next month, the speaker at the Silicon Valley Linux User’s Group is Marc Andreessen, founder of Netscape. The day before, the source code for Netscape’s browser had been released on the Internet, and Andreessen is here as part of the general celebration. The mood tonight is not cerebral. Andreessen is expansive, talks about the release of the source code as “a return to our roots on a personal level.” Tom Paquin, manager of Mozilla, the organization created to manage the Netscape source code, is unabashed in his belief that free and open source can compete with the juggernaut Microsoft, with the giants Oracle and Sun. He almost seems to believe that Netscape’s release of the source isn’t an act of desperation against the onslaught of the Microsoft browser. “Technologists drive this industry,” he says, whistling in the dark. “The conventional wisdom is it’s all marketing, but it’s not.”

Outside, a bus is waiting to take the attendees up to San Francisco, where a big party is being held in a South of Market disco joint called the Sound Factory. There is a long line outside, backed up almost to the roadway of the Bay Bridge. Andreessen enters, and he is followed around by lights and cameras like a rock star. In all this celebration, for just this one night, it’s almost possible to believe that technologists do indeed matter to technology, that marketing is not all, and all we have to do is get the code to the people who might understand it and we can reclaim our technical souls.

Meanwhile, Andreessen disappears into a crush of people, lights flash, a band plays loudly and engineers, mostly men, stand around holding beer bottles. Above us, projected onto a screen that is mostly ignored, is what looks like the Netscape browser source code. The red-blue-green guns on the color projector are not well focused. The code is too blurry, scrolling by too quickly, to be read.

My intention had been to buy an upgrade to Windows NT Server, which was a completely sensible thing for me to be doing. A nice, clean, up-to-date system for an extra machine was the idea, somewhere to install my clients’ software; a reasonable, professional choice in a world where Microsoft platforms are everywhere. But somehow I left the store carrying a box of Linux from a company called Slackware. Linux: home-brewed, hobbyist, group-hacked. UNIX-like operating system created in 1991 by Linus Torvalds then passed around from hand to hand like so much anti-Soviet samizdat. Noncommercial, sold on the cheap mainly for the cost of the documentation, impracticable except perhaps for the thrill of actually looking at the source code and utterly useless to my life as a software engineering consultant.

But buying Linux was no mistake. For the mere act of installing the system — stripping down the machine to its components, then rebuilding its capabilities one by one — led me to think about what has happened to the profession of programming, and to consider how the notion of technical expertise has changed. I began to wonder about the wages, both personal and social, of spending so much time with a machine that has slowly absorbed into itself as many complications as possible, so as to present us with a fagade that says everything can and should be “easy.”

I began by ridding my system of Microsoft. I came of technical age with UNIX, where I learned with power-greedy pleasure that you could kill a system right out from under yourself with a single command. It’s almost the first thing anyone teaches you: Run as the root user from the root directory, type in rm -r f *, and, at the stroke of the ENTER key, gone are all the files and directories. Recursively, each directory deleting itself once its files have been deleted, right down to the very directory from which you entered the command: the snake swallowing its tail. Just the knowledge that one might do such great destruction is heady. It is the technical equivalent of suicide, yet UNIX lets you do it anyhow. UNIX always presumes you know what you’re doing. You’re the human being, after all, and it is a mere operating system. Maybe you want to kill off your system.

But Microsoft was determined to protect me from myself. Consumer-oriented, idiot-proofed, covered by its pretty skin of icons and dialog boxes, Windows refused to let me harm it. I had long ago lost my original start-up disk, the system was too fritzed to make a new one and now it turned away my subterfuges of DOS installation diskette, boot disks from other machines, later versions of utilities. Can’t reformat active drive. Wrong version detected. Setup designed for systems without an operating system; operating system detected; upgrade version required. A cascade of error messages, warnings, beeps; a sort of sound and light show — the Wizard of Oz lighting spectacular fireworks to keep me from flinging back the curtain to see the short fat bald man.

For Microsoft’s self-protective skin is really only a show, a lure to the determined engineer, a challenge to see if you’re clever enough to rip the covers off. The more it resisted me, the more I knew I would enjoy the pleasure of deleting it.

Two hours later, I was stripping down the system. Layer by layer it fell away. Off came Windows NT 3.51; off came a wayward co-installation of Windows 95 where it overlaid DOS. I said goodbye to video and sound; goodbye wallpaper; goodbye fonts and colors and styles; goodbye windows and icons and menus and buttons and dialogs. All the lovely graphical skins turned to so much bitwise detritus. It had the feel of Keir Dullea turning off the keys to HAL’s memory core in the film “2001,” each keyturn removing a “higher” function, HAL’s voice all the while descending into mawkish, babyish pleading. Except that I had the sense that I was performing an exactly opposite process: I was making my system not dumber but smarter. For now everything on the system would be something put there by me, and in the end the system itself would be cleaner, clearer, more knowable — everything I associate with the idea of “intelligent.”

What I had now was a bare machine, just the hardware and its built-in logic. No more Microsoft muddle of operating systems. It was like hosing down your car after washing it: the same feeling of virtuous exertion, the pleasure of the sparkling clean machine you’ve just rubbed all over. Yours. Known down to the crevices. Then, just to see what would happen, I turned on the computer. It powered up as usual, gave two long beeps, then put up a message in large letters on the screen:

NO ROM BASIC

What? Had I somehow killed off my read-only memory? It doesn’t matter that you tell yourself you’re an engineer and game for whatever happens. There is still a moment of panic when things seem to go horribly wrong. I stared at the message for a while, then calmed down: It had to be related to not having an operating system. What else did I think could happen but something weird?

But what something weird was this exactly? I searched the Net, found hundreds of HOW-TO FAQs about installing Linux, thousands about uninstalling operating systems — endless pages of obscure factoids, strange procedures, good and bad advice. I followed trails of links that led to interesting bits of information, currently useless to me. Long trails that ended in dead ends, missing pages, junk. Then, sometime about 1 in the morning, in a FAQ about Enhanced IDE, was the answer:

8.1. Why do I get NO ROM BASIC, SYSTEM HALTED?

This should get a prize for the PC compatible’s most obscure error message. It usually means you haven’t made the primary partition bootable …

The earliest true-blue PCs had a BASIC interpreter built in, just like many other home computers those days. Even today, the Master Boot Record (MBR) code on your hard disk jumps to the BASIC ROM if it doesn’t find any active partitions. Needless to say, there’s no such thing as a BASIC ROM in today’s compatibles….

I had not seen a PC with built-in BASIC in some 16 years, yet here it still was, vestigial trace of the interpreter, something still remembering a time when the machine could be used to interpret and execute my entries as lines in a BASIC program. The least and smallest thing the machine could do in the absence of all else, its one last imperative: No operating system! Look for BASIC! It was like happening upon some primitive survival response, a low-level bit of hard wiring, like the mysterious built-in knowledge that lets a blind little mouseling, newborn and helpless, find its way to the teat.

This discovery of the trace of BASIC was somehow thrilling — an ancient pot shard found by mistake in the rubble of an excavation. Now I returned to the FAQs, lost myself in digging, passed another hour in a delirium of trivia. Hex loading addresses for devices. Mysteries of the BIOS old and new. Motherboards certified by the company that had written my BIOS and motherboards that were not. I learned that my motherboard was an orphan. It was made by a Taiwanese company no longer in business; its BIOS had been left to languish, supported by no one. And one moment after midnight on Dec. 31, 1999, it would reset my system clock to … 1980? What? Why 1980 and not zero? Then I remembered: 1980 was the year of the first IBM PC. 1980 was Year One in desktop time.

The computer was suddenly revealed as palimpsest. The machine that is everywhere hailed as the very incarnation of the new had revealed itself to be not so new after all, but a series of skins, layer on layer, winding around the messy, evolving idea of the computing machine. Under Windows was DOS; under DOS, BASIC; and under them both the date of its origins recorded like a birth memory. Here was the very opposite of the authoritative, all-knowing system with its pretty screenful of icons. Here was the antidote to Microsoft’s many protections. The mere impulse toward Linux had led me into an act of desktop archaeology. And down under all those piles of stuff, the secret was written: We build our computers the way we build our cities — over time, without a plan, on top of ruins.

My Computer. This is the face offered to the world by the other machines in the office. My Computer. I’ve always hated this icon — its insulting, infantilizing tone. Even if you change the name, the damage is done: It’s how you’ve been encouraged to think of the system. My Computer. My Documents. Baby names. My world, mine, mine, mine. Network Neighborhood, just like Mister Rogers’.

On one side of me was the Linux machine, which I’d managed to get booted from a floppy. It sat there at a login prompt, plain characters on a black-and-white screen. On the other side was a Windows NT system, colored little icons on a soothing green background, a screenful of programming tools: Microsoft Visual C++, Symantec Visual Cafe, Symantec Visual Page, Totally Hip WebPaint, Sybase PowerBuilder, Microsoft Access, Microsoft Visual Basic — tools for everything from ad hoc Web-page design to corporate development to system engineering. NT is my development platform, the place where I’m supposed to write serious code. But sitting between my two machines — baby-faced NT and no-nonsense Linux — I couldn’t help thinking about all the layers I had just peeled off the Linux box, and I began to wonder what the user-friendly NT system was protecting me from.

Developers get the benefit of visual layout without the hassle of having to remember HTML code.

– Reviewers’ guide to Microsoft J++

Templates, Wizards and JavaBeans Libraries Make Development Fast
– Box for Symantec’s Visual Cafe for Java

Simplify application and applet development with numerous wizards
– Ad for Borland’s JBuilder in the Programmer’s Paradise catalog

Thanks to IntelliSense, the Table Wizard designs the structure of your business and personal databases for you.
– Box for Microsoft Access

Developers will benefit by being able to create DHTML components without having to manually code, or even learn, the markup language.
– Review of J++ 6.0 in PC Week, March 16, 1998.

Has custom controls for all the major Internet protocols (Windows Sockets, FTP, Telnet, Firewall, Socks 5.0, SMPT, POP, MIME, NNTP, Rcommands, HTTP, etc.). And you know what? You really don’t need to understand any of them to include the functionality they offer in your program.
– Ad for Visual Internet Toolkit from the Distinct Corp. in the Components Paradise catalog

My programming tools were full of wizards. Little dialog boxes waiting for me to click “Next” and “Next” and “Finish.” Click and drag and shazzam! — thousands of lines of working code. No need to get into the “hassle” of remembering the language. No need to even learn it. It is a powerful siren-song lure: You can make your program do all these wonderful and complicated things, and you don’t really need to understand.

In six clicks of a wizard, the Microsoft C++ AppWizard steps me through the creation of an application skeleton. The application will have a multidocument interface, database support from SQL Server, OLE compound document support as both server and container, docking toolbars, a status line, printer and print-preview dialogs, 3-D controls, messaging API and Windows sockets support; and, when my clicks are complete, it will immediately compile, build and execute. Up pops a parent and child window, already furnished with window controls, default menus, icons and dialogs for printing, finding, cutting and pasting, saving and so forth. The process takes three minutes.

Of course, I could look at the code that the Wizard has generated. Of course, I could read carefully through the 36 generated C++ class definitions. Ideally, I would not only read the code but also understand all the calls on the operating system and all the references to the library of standard Windows objects called the Microsoft Foundation Classes. Most of all, I would study them until I knew in great detail the complexities of servers and containers, OLE objects, interaction with relational databases, connections to a remote data source and the intricacies of messaging — all the functionality AppWizard has just slurped into my program, none of it trivial.

But everything in the environment urges me not to. What the tool encourages me to do now is find the TODO comments in the generated code, then do a little filling in — constructors and initializations. Then I am to start clicking and dragging controls onto the generated windows — all the prefabricated text boxes and list boxes and combo boxes and whatnot. Then I will write a little code that hangs off each control.

In this programming world, the writing of my code has moved away from being the central task to become a set of appendages to the entire Microsoft system structure. I’m a scrivener here, a filler-in of forms, a setter of properties. Why study all that other stuff, since it already works anyway? Since my deadline is pressing. Since the marketplace is not interested in programs that do not work well in the entire Microsoft structure, which AppWizard has so conveniently prebuilt for me.

This not-knowing is a seduction. I feel myself drifting up, away from the core of what I’ve known programming to be: text that talks to the system and its other software, talk that depends on knowing the system as deeply as possible. These icons and wizards, these prebuilt components that look like little pictures, are obscuring the view that what lies under all these cascading windows is only text talking to machine, and underneath it all is something still looking for a BASIC interpreter. But the view the wizards offer is pleasant and easy. The temptation never to know what underlies that ease is overwhelming. It is like the relaxing passivity of television, the calming blankness when a theater goes dark: It is the sweet allure of using.

My programming tools have become like My Computer. The same impulse that went into the Windows 95 user interface — the desire to encapsulate complexity behind a simplified set of visual representations, the desire to make me resist opening that capsule — is now in the tools I use to write programs for the system. What started out as the annoying, cloying face of a consumer-oriented system for a naive user has somehow found its way into C++. Dumbing-down is trickling down. Not content with infantilizing the end user, the purveyors of point-and-click seem determined to infantilize the programmer as well.

But what if you’re an experienced engineer? What if you’ve already learned the technology contained in the tool, and you’re ready to stop worrying about it? Maybe letting the wizard do the work isn’t a loss of knowledge but simply a form of storage: the tool as convenient information repository.

(To be continued.)

It happened in the way of all true-life humiliations: when you think you’re better than the people around you. I had decided to leave the project; I agreed to help find another consultant, train another team. There I was, finding my own replacement. I called a woman I thought was capable, experienced — and my junior. I thought I was doing her a favor; I thought she should be grateful.

She arrived with an entourage of eight, a group she had described on the telephone as “Internet heavy-hitters from Palo Alto.” They were all in their early 30s. The men had excellent briefcases, wore beautiful suits, and each breast pocket bulged ever so slightly with what was later revealed to be a tiny, exquisite cellular phone. One young man was so blonde, so pale-eyed, so perfectly white, he seemed to have stepped out of a propaganda film for National Socialism. Next to him was a woman with blonde frosted hair, chunky real-gold bracelets, red nails, and a short skirt, whom I took for a marketing type; she turned out to be in charge of “physical network configuration.” This group strutted in with all the fresh-faced drive of techno-capitalism, took their seats beneath the AIDS prevention posters (“Warriors wear shields with men and women!” “I take this condom everywhere I bring my penis!”), and began their sales presentation.

They were pushing an intranet. This is a system using all the tools of the Internet — Web browser, net server — but on a private network. It is all the rage, it is cool, it is what everyone is talking about. It is the future and, as the woman leading the group made clear, what I have been doing is the past. “An old-style enterprise system” is what she called the application as I had built it, “a classic.”

My client was immediately awed by their wealth, stunned silent by their self-assurance. The last interviewee had been a nervous man in an ill-fitting suit, shirt washed but not quite ironed, collar crumpled over shiny polyester tie. Now here came these smooth new visitors, with their “physical network configuration” specialist, their security expert, their application designer, and their “technology paradigm.” And they came with an attitude — the AIDS project would be lucky to have them.

It was not only their youth and high-IQ arrogance that bothered me. It wasn’t just their unbelievable condescension (“For your edification, ma’am,” said one slouch-suited young man by way of beginning an answer to one of my questions). No, this was common enough. I’d seen it all before, everywhere, and I’d see it again in the next software engineer I’d meet. What bothered me was just that: the ordinariness of it. From the hostile scowl of my own programmer to the hard-driving egos of these “Internet heavy-hitters”: normal as pie. There they were on the cutting edge of our profession, and their arrogance was as natural as breathing. And in those slow moments while their vision of the future application was sketched across the white boards — intranet, Internet, cool, hip, and happening — I knew I had utterly and completely lost that arrogance in myself.

I missed it. Suddenly and inexplicably, I wanted my arrogance back. I wanted to go back to the time when I thought that, if I tinkered a bit, I could make anything work. That I could learn anything, in no time, and be good at it. The arrogance is a job requirement. It is the confidence-builder that lets you keep walking toward the thin cutting edge. It’s what lets you forget that your knowledge will be old in a year, you’ve never seen this new technology before, you have only a dim understanding of what you’re doing, but — hey, this is fun — and who cares since you’ll figure it all out somehow.

But the voice that came out of me was not having fun.

“These intranet tools aren’t proven,” I found myself saying. “They’re all release 1.0 — if that. Most are in beta test. And how long have you been doing this? What — under a year? Exactly how many intranets have you implemented successfully?”

My objections were real. The whole idea wasn’t a year old. The tools weren’t proven. New versions of everything were being released almost as we spoke. And these heavy-hitters had maybe done one complete intranet job before this — maybe. But in the past none of this would have bothered me. I would have seen it as part of the usual engineering trade-offs, get something, give up something else. And the lure of the new would have been irresistible: the next cover to take off, the next black box to open.

But now, no. I didn’t want to take off any covers. I didn’t want to confront any more unknowns. I simply felt exhausted. I didn’t want to learn the intranet, I wanted it to be a bad idea, and I wanted it all just to go away.
“And what about network traffic?” I asked. “Won’t this generate a lot of network traffic? Aren’t you optimizing for the wrong resource? I mean, memory and disk on the desktop are cheap, but the network bandwidth is still scarce and expensive.”

More good objections, more justifications for exhaustion.

“And intranets are good when the content changes frequently — catalogs, news, that kind of stuff. This is a stable application. The dataset won’t change but once a year.”

Oh, Ellen, I was thinking, What a great fake you are. I was thinking this because, even as I was raising such excellent issues, I knew it was all beside the point. What I was really thinking was: I have never written an intranet program in my life, I have never hacked on one, I have never even seen one. What I was really feeling was panic.

I’d seen other old programmers act like this, get obstructionist and hostile in the face of their new-found obsolescence, and there I was, practically growing an old guy’s gut on the spot. But the role had a certain momentum, and once I’d stepped on the path of the old programmer, there seemed to be no way back. “And what happens after you leave?” I asked. “There just aren’t that many intranet experts out there. And they’re expensive. Do you really think this technology is appropriate for this client?”

“Well,” answered the woman I’d invited, the one I’d thought of as my junior, the one I was doing a favor, “you know, there are the usual engineering trade-offs.”

Engineering trade-offs. Right answer. Just what I would have said once.

“And besides,” said the woman surrounded by her Internet heavy-hitters, “like it or not, this is what will be happening in the future.”

The future. Right again. The new: irresistible, like it or not.

But I didn’t like it. I was parting ways with it. And exactly at that moment, I had a glimpse of the great, elusive cutting edge of technology. I was surprised to see that it looked like a giant cosmic Frisbee. It was yellow, rotating at a great rate, and was slicing off into the universe, away from me.

I learned to program a computer in 1971; my first programming job came in 1978. Since then, I have taught myself six higher-level programming languages, three assemblers, two data-retrieval languages, eight job-processing languages, seventeen scripting languages, ten types of macros, two object-definition languages, sixty-eight programming-library interfaces, five varieties of networks, and eight operating environments — fifteen, if you cross-multiply the distinct combinations of operating systems and networks. I don’t think this makes me particularly unusual. Given the rate of change in computing, anyone who’s been around for a while could probably make a list like this.

This process of remembering technologies is a little like trying to remember all your lovers: you have to root around in the past and wonder, Let’s see. Have I missed anybody? In some ways, my personal life has made me uniquely suited to the technical life. I’m a dedicated serial monogamist — long periods of intense engagement punctuated by times of great restlessness and searching. As hard as this may be on the emotions, it is a good profile for technology.

I’ve managed to stay in a perpetual state of learning only by maintaining what I think of as a posture of ignorant humility. This humility is as mandatory as arrogance. Knowing an IBM mainframe — knowing it as you would a person, with all its good qualities and deficiencies, knowledge gained in years of slow anxious probing — is no use at all when you sit down for the first time in front of a UNIX machine. It is sobering to be a senior programmer and not know how to log on.

There is only one way to deal with this humiliation: bow your head, let go of the idea that you know anything, and ask politely of this new machine, “How do you wish to be operated?” If you accept your ignorance, if you really admit to yourself that everything you know is now useless, the new machine will be good to you and tell you: here is how to operate me.

Once it tells you, your single days are over. You are involved again. Now you can be arrogant again. Now you must be arrogant: you must believe you can come to know this new place as well as the old — no, better. You must now dedicate yourself to that deep slow probing, that patience and frustration, the anxious intimacy of a new technical relationship. You must give yourself over wholly to this: you must believe this is your last lover.

I have known programmers who managed to stay with one or two operating systems their entire careers — solid married folks, if you will. But, sorry to say, our world has very little use for them. Learn it, do it, learn another: that’s the best way. UNIX programmers used to scoff at COBOL drones, stuck year by year in the wasteland of corporate mainframes. Then, just last year, UNIX became old-fashioned, Windows NT is now the new environment, and it’s time to move on again. Don’t get comfortable, don’t get too attached, don’t get married. Fidelity in technology is not even desirable. Loyalty to one system is career-death. Is it any wonder that programmers make such good social libertarians?

Every Monday morning, three trade weeklies come sliding through my mail slot. I’ve come to dread Mondays, not for the return to work but for these fat loads of newness piled on the floor waiting for me. I cannot possibly read all those pages. But then again, I absolutely must know what’s in them. Somewhere in that pile is what I must know and what I must forget. Somewhere, if I can only see it, is the outline of the future.

Once a year, I renew my subscription to the Microsoft Professional Developer Network. And so an inundation of CD-ROMs continues. Quarterly, seasonally, monthly, whenever — with an odd and relentless periodicity — UPS shows up at my door with a new stack of disks. New versions of operating systems, libraries, tools — everything you need to know to keep pace with Microsoft. The disks are barely loaded before I turn around and UPS is back again: a new stack of disks, another load of newness.

Every month come the hardware and software catalogs: the Black Box networking book, five hundred pages of black-housed components turned around to show the back panel; PCs Compleat, with its luscious just-out laptops; and my favorite, the Programmer’s Paradise, on the cover a cartoon guy in wild bathing trunks sitting under a palm tree. He is all alone on a tiny desert island but he is happy: he is surrounded by boxes of the latest programming tools.

Then there is the Microsoft Systems Journal, a monthly that evangelizes the Microsoft way while handing out free code samples. The Economist, to remind myself how my libertarian colleagues see the world. Upside, Wired, The Red Herring: the People magazines of technology. The daily Times and Wall Street Journal. And then, as if all this periodical literature were not enough, as if I weren’t already drowning in information — here comes the Web. Suddenly, monthly updates are unthinkable, weekly stories laughable, daily postings almost passé. “If you aren’t updating three times a day, you’re not realizing the potential of the medium,” said one pundit, complaining about an on-line journal that was refreshing its content — shocking! — only once a day.

There was a time when all this newness was exhilarating. I would pore over the trade weeklies, tearing out pages, saving the clips in great messy piles. I ate my meals reading catalogs. I pestered nice young men taking orders on the other end of 800 phone lines; I learned their names and they mine. A manual for a new programming tool would call out to me like a fussy, rustling baby from inside its wrapping.

What has happened to me that I just feel tired? The weeklies come, and I barely flip the pages before throwing them on the recycle pile. The new catalogs come and I just put them on the shelf. The invoice for the Professional Developer Subscription just came from Microsoft: I’m thinking of doing the unthinkable and not renewing.

I’m watching the great, spinning, cutting edge slice away from me — and I’m just watching. I’m almost fascinated by my own self-destructiveness. I know the longer I do nothing, the harder it will be to get back. Technologic time is accelerated, like the lives of very large dogs: six months of inattention might as well be years. Yet I’m doing nothing anyway. For the first time in nineteen years, the new has no hold on me. This terrifies me. It also makes me feel buoyant and light.