CAMBRIDGE, MASS. -- It was getting down to the wire for Arny Epstein. With a compact disc player at his side and a computer keyboard beneath his fingertips, Epstein raced to complete the most daunting task in his 10 years as a computer programmer.

For weeks, he and his co-workers at Lotus Development Corp. had struggled to correct thousands of problems in a software program they had spent six years building. They were like carpenters who, after crafting a showpiece home, had to rush back in to fix their mistakes, any of which, if not corrected, could bring the whole structure crumbling down.

In a few days, the Lotus software would be sealed onto computer disks and shipped to a few select customers who would serve as guinea pigs to establish how well it could balance books or plan a company's future.

With more than 10,000 flaws uncovered so far in the Lotus 1-2-3 program, there was virtually no hope of getting rid of them all. Yet failure to find and fix the most important ones could shatter Lotus's reputation as a leading publisher of software and would be a staggering blow to the diligent software designers who had devoted 18-hour days to polishing their product.

As they raced frantically last autumn to scrub the errors from their program, Epstein and his colleagues had come nearly to the end of a tortuous process that ranks among the least refined in American industry -- the development of computer software. Despite software's vital role as an engine of modern society, large-scale production lacks the consistency and reliability found in more mature trades and industries.

A visit to Lotus, a large software producer that itself missed two important product deadlines last year, offers a telling picture of the frustrations that consume the nation's estimated 1 million to 2 million professional programmers and the countless more who claim it as a hobby. In striving to reduce the imprecise needs of humans into ruthlessly logical, step-by-step instructions understandable to inflexible computers, programmers struggle to meld discipline with creative free-thinking, to follow rules while leaving room for the occasional offbeat idea.

At no time is this tension more evident than in the last-minute chase to fix mistakes in the programs -- "bugs," in the parlance of programmers. Their task is akin to editing a novel thousands of pages in length, in which each chapter was written by a different person. Some of these errors are grammatical; others are flaws of logic that upon close scrutiny create inconsistencies in the novel's plot.

The challenge facing programmers is to delicately repair such defects without disrupting anything else.

A Giddy Tension in the Air

At one Lotus software operation here, a modern office building along the Charles River in Cambridge, a giddy tension gripped programmers as they ground through the final days before the firm was scheduled to ship a trial version of the 1-2-3/G spreadsheet -- a computer program enhanced with fancy graphics that organizes numerical calculations in rows and columns and can perform thousands of interrelated functions at breakneck speed.

Programmers, who also are known as developers, bounced rubber balls several stories down a central atrium and shot paper airplanes across it. They raced radio-controlled cars down the hallways and tried their luck at the Eight Ball Deluxe pinball machine, conveniently located near the central computer printer.

Everywhere -- in the long hallways, in offices, on well-worn paths between Lotus buildings -- developers in bluejeans brainstormed over the new software flaws being unearthed faster than they could be fixed. They knew that many bugs would have to be ignored for the time being, though hopefully none of those remaining would grind the program to a halt. Luckily, this first version of 1-2-3/G would go only to test users, so developers would have a chance later to correct more bugs before final product shipment. Already, in the crush of deadline, a carefully conceived plan to keep track of last-minute changes had fallen by the wayside.

Epstein, a guru of sorts, tried to settle into his office, amid three computer terminals and boxes stacked everywhere. With the "Brandenburg" Concerto playing on the CD player, he launched the attack on the 68 bugs he had been assigned.

Bugs quickly become a matter of personal concern to programmers who wrote the defective lines of software, or so-called code. The number of bugs in the code that developers "own" has a lot to do with their self-esteem, which in turn has a lot to do with their success on the job. For programmers, life consists of an avalanche of negative feedback.

"Psychologically speaking, it's bad to have a lot of bugs," said Rob Rosen, 33, who along with Epstein was one of six team leaders among the 100-plus people working on the 1-2-3/G product. "I've got one guy down the hall who has been working his head off and he has 130 bugs."

At the moment, Epstein had a neatly numbered list beginning with bug No. 113912, an identification assigned by a computer that tracks all the problems uncovered by Lotus's staff of testers. Some of his had persisted for weeks. All were labeled with a degree of severity. Almost flippantly and seemingly to dodge responsibility, Epstein sprinted through his roster, repeatedly proclaiming, "It can't possibly be mine" or "So what?" when he encountered a bug of seemingly minor consequence.

But one in particular was difficult to dispute.

The mistake was akin to spelling one's own name wrong. Just a few days before 1-2-3/G was to be shipped, someone had discovered that the letter "G" had been left off the name on the first display screen users would see when they turned on the program. Epstein dived into the code and in moments had the repair completed. Unfortunately, few flaws are that easy to correct.

Epstein appeared at ease with the intricacies of code, but it doesn't take many hours of observation to realize that his is an acquired talent. At age 41, he is an old man at Lotus, and, like many of his peers, he didn't grow up wanting to be a programmer. Epstein's professional life began as a Harvard astrophysicist, until a certain mystique lured him to software development.

"It's an art form for me," Epstein said. "I can just walk up to the computer and it's a lump of clay. I can make it do whatever I want it to."

These days, he mostly has to make it do what others want. A constant stream of programmers, attracted by his calm manner and clear thinking, bring their coding queries to Epstein's cluttered office. Epstein is valued for his uncanny programming brilliance, especially his ability to feel in his gut how different pieces of a software program interact.

"It's like you built a two-door car and someone said, 'I want four,' and you have to figure out how to put on four without having the whole car fall apart," colleague Rosen explained. "If you went to design school, they would tell you that if you want a four-door car you have to design the frame that way," whereas Epstein could concoct a method of achieving the goal without destroying the rest of the structure, Rosen said.

But Epstein is admired just as much for his quirkier qualities. On weekends, he can be found on the golf course in summer, on a cross-country ski course in winter. During meetings at Lotus, the lanky, dark-haired developer is known to pull out his orange, battery-powered squirt gun and take aim at anyone who voices a stupid idea. "He's respected for not being totally normal," Rosen allowed.

Earning One's Stripes Epstein also has earned his status as a mentor because he has "shipped a product" -- that is, he actually worked on another software program long enough to see it delivered to customers. That's how developers earn their stripes; Epstein calls it "a transformational experience."

Getting a product out, Epstein said, reminds developers of something easily forgotten: "The real success is that it helped a million people do their work, and not that 200 people thought it was the neatest product there ever was."

The result of Epstein's popularity is that his daytime hours are, in programmer talk, "interrupt driven."

One such interruption was a visit from 31-year-old Debbie Rhodes, an intense programmer who spends almost her entire day behind a keyboard trying to think like a computer and translate that into software instructions, line by line. Three times, the programs Rhodes worked on at another firm were killed. Never has she experienced the satisfaction of seeing a program she worked on shipped to customers.

Rhodes was confused and perturbed that day. Diet Coke in hand, she barged into Epstein's office and slumped into a chair. The nature of Rhodes's problem was a typical, yet exasperating one: A change in one portion of the program, which Epstein had requested a day earlier, had caused an unexpected glitch in Rhodes's portion of the software. Such dilemmas occur because computer instructions are not necessarily read chronologically. Rather, the lines of software code may be run by computers, over time, in a virtually endless variety of sequences.

That means there can be an astonishing number of different paths through the code, with each route depending on the data at hand and the wishes of the user. A virtually impossible chore for developers is to understand the potential pitfalls on each path, and -- as Rhodes and Epstein learned -- that's made even more difficult when changes to the code are introduced.

The number of different paths can border on the absurd: Software experts have calculated that there are more routes through a section of the Federal Aviation Administration's air traffic control software than there are atoms in the universe.

With 500,000 lines of code in the 1-2-3/G program, no one at Lotus could grasp the entire picture. One way to cope with complex software development, as Lotus team leader Rosen found, is to break it up into pieces and turn them over to innovative individuals or small groups.

Rosen, an ancient-history major in college, approaches programming as an intellectual puzzle, like tackling Rubik's Cube. When stumped, he resorts to diagraming on a white board in his office so he can visualize how to logically untangle his mess. Then he returns to the computer screen to translate that image into seemingly inexplicable code -- statements like "if ( VWLYVWPNPROP1(ly)- VPPGVstart.DCdpage == cd{0}.array{VLEVEL} )."

All the sophisticated management techniques in the world can't help Rosen get his work done. Often when he is baffled about how to turn a certain task into software code, the "Eureka!" sensation strikes in the middle of the night or during a TV show or while riding his bike home.

"It was as if you'd think about it and you weren't really thinking about it. You'd finished supper and you were halfway through 'Miami Vice' and all of a sudden you say, 'Yeah, that's how it's going to work.' "

As Rosen and a colleague learned, sometimes finding the solution means breaking the rules. Only by skirting prescribed procedures could they tweak 1-2-3/G so it would run fast enough to meet acceptable standards.

Their experiences illustrate a long-time maxim easily forgotten in these days of huge programming teams: More code will get written faster if you limit the number of people involved. Only then can the best developers shine, proving that they're intellectual daredevils at heart.

This streak of individualism is a hallmark of programmers borne out over the years. A study conducted by a University of Colorado professor found that software specialists scored highest among 500 professions in their need for challenging work but lowest in their need for social interaction.

Balancing Creativity, Discipline As the nation thirsts for more computerization, balancing the urge for free-thinking individualism with a measure of disciplined conformity is quickly becoming a central challenge for the software industry.

Completing large programs, with hundreds of people involved, demands a splitting up of the programming chore into small pieces. But with too narrow a focus, bright developers are at risk of losing the intuition that can work so well when they are able to mentally grasp an entire project.

At Lotus, 1-2-3/G general manager Marty Fahey figures that his team proved fairly successful at meeting this challenge, producing in the end a software package that appears, at least for now, to contain relatively few bugs.

"You've got to have some structure ... but you also have to allow them to do great things," Fahey said. "You have to keep the magic in the process." NEXT: Automating the battlefield

There are six general stages of software development. In reality, the process is cyclical -- developers already in one stage may have to return to a previous phase -- and in many small software shops the steps often are not formally followed. The stages:

Setting Requirements -- The process of deciding what the software is supposed to do, ideally involving both computer experts and the ultimate users. This phase involves trying to anticipate every circumstance in which the software might be used.

Designing -- Determining how to make the computer system achieve the requirements, as the architects of a house would do after hearing the buyers describe their dream home.

Coding -- The laborious, line by line writing of the detailed instructions. In perhaps the most famous coding error, the 1962 Mariner satellite headed for Venus was blown up minutes after launch when it veered off course, in part because of a missing "bar" in one line of code.

Debugging -- Weeding out errors. But when programmers fix one mistake in their code, they can cause another.

Testing -- The systematic search for flaws in how the software actually operates. Computer specialists differ on how best to test. Some favor exhaustive trial-and-error testing that mimics how a customer would use software, while others favor employing mathematical proofs.

Maintaining -- The ongoing process of making the inevitable corrections and improvements to a software program. U.S. software specialists spend about half their time on maintenance.

Software, the language of technological society, is a series of written rules and commands that instruct computers and electrical equipment how to solve problems, from something as simple as indenting this paragraph to routing long-distance telephone calls across the country.

The instructions create a series of choices that are direct enough for computers to deal with in a simple yes-no fashion. That is the kind of decision a computer component makes because of the unique way it operates, like an electrical switch that is either on or off. Software designers instruct computers to check with information stored in their memories before making decisions. A simple software instruction might be: IF THIS IS TRUE, DO THAT. OTHERWISE, DON'T DO IT. DO SOMETHING ELSE. The more complex the problem, the more decision-making points that are needed. Software programs for huge military and business computers can contain millions of such instructions and rules that together make up the "lines of code."

To understand the software designer's job, picture a 21st century tourist who wants to drive from 15th and K streets NW to Georgetown.

Instead of relying on a map, he has a rental car equipped with a computer that has been programmed with rules and choices that enable it to navigate through Washington's streets. The driver begins by typing in his current location and where he wants to go. The software program instructs the computer to determine the best route by sorting through the data in its memory. A software instruction might read: "DOES K STREET HEAD WEST? IF YES, GO ON K. IF NOT, CHECK THE NEXT STREET."

At every intersection along the way, similar questions are posed and answered within the computer, unbeknownst to the driver, who simply follows the orders displayed on a screen telling him where to go.

Now add a new level of complexity. This time, the instructions are, find the fastest route to Georgetown, not the shortest. Suppose that the computer was electronically fed minute-by-minute information about traffic congestion. Then the choices might be: "DOES THIS STREET LEAD TOWARD GEORGETOWN? IS IT MORE OR LESS CROWDED THAN THE NEST STREET?" At each intersection, the question would be complicated by new information.

The problem could be made even tougher by directing the computer to find the fastest route to Georgetown AND locate the most likely place to find a parking spot.

The software designer must provide the computer with a master plan of all the rules and directions that are needed to find the correct answer at each intersection, each time taking into account the destination and preferences of the particular tourist in the car.

There are almost limitless possible routes that the computer can take through the District. This is known as the "combinatorial explosion" of potential paths through software code and helps explain the presence of "bugs," or errors - so called because of a long-ago computer breakdown caused when a dead moth prevented a tiny switch from operating properly. Lacking common sense, a computer that encounters a bug and is unable to work around it won't perform as expected.

Bugs come in several varieties, all caused by human error. For example:

Software designers may fail to include information a computer would need to make proper choices, such as ignoring when certain streets switch from two-way to one-way traffic in rush hour.

Programmers can introduce errors by using incorrect formulas: -for example, requiring the computer to assess streets in alphabetical order, when in fact there is no J Street. Or they might install the wrong formula for timing traffic lights on a certain street, thereby throwing off the calculations used to determine quickest routes.

A programmer could befuddle the computer by writing instructions with incorrect language or punctuation -- telling the computer to turn "rigt" at an intersection, a word it could not decipher.

Software may fail to anticipate unexpected events: the overnight closing of a road for repairs, which could cause the computer to stop working, or "crash."