But now when Windholtz creates code, he does so with a comrade at his side--one of the tenets of the software development methodology called Extreme Programming.

"Sometimes if you're coding alone, you end up going off on the wrong thing for a while," Windholtz said. "If you're 'pair programming,' that doesn't happen, or it doesn't happen for very long...As soon as one person runs out of ideas, the other person just picks up on them."

Welcome to a new world of computer programming--and say goodbye to the image of the solitary code jockey working late into the night on a diet of cold pizza and warm cola. Better yet, Extreme Programming can help produce software that is not only of higher quality, but is produced much more quickly than is the norm.

The goal is to make the code-writing process less random, get software to customers more quickly, and eliminate the inevitable onslaught of bugs discovered during the traditional integration phases.

The methodology is gaining more and more devotees. Ford Motor, Chrysler and IBM are among the companies using Extreme Programming in at least some capacity.

John Giblin, senior vice president of engineering at Dublin, Ireland-based software company Iona, turned to Extreme last summer to slash software delivery times. "Sometimes because of the length of development cycles, by the time the product is developed, the original set of requirements is only partially relevant," Giblin said.

Since using Extreme for Iona's application server product, Giblin has seen strong results. "At a minimum, we're getting products to the market much faster," he said.

The antidote
The methodology was invented in 1996, when automaker Chrysler called upon Kent Beck, a software developer, to save a project known as Chrysler Comprehensive Compensation, or C3. The cornerstone of Beck's formula was a set of directions for keeping code "elegantly written." The C3 system now provides monthly payroll information for Chrysler employees.

It's easy to see why other companies are turning to Extreme Programming as an antidote to the scattershot way software has been produced for decades--and especially during the stock market's bull run of the 1990s. Many cash-rich technology companies produced software by hiring as many top-level programmers as possible--regardless of how much it cost to recruit and retain them.

Once assembled, the programmers were closeted in offices for weeks or months to bang out code. The individual efforts were then glued together and submitted to the long process of debugging.

Ron Jeffries, an Extreme aficionado, has worked closely with Beck and co-authored the book "Extreme Programming Installed." Jeffries offers his own critique of traditional approaches to software development. "You hire a bunch of programmers, tell them what you want, and there's no organizational structure," he said.

More and more companies may begin turning to Extreme Programming, especially during the current economic slowdown, as they look for new ways to improve efficiency and stamp out defects in software long before they appear in the final product.

"There's an expectation when you deliver a solution that it's perfect," said David Osborne, chief technology officer with Plural, a New York-based e-business consulting company that serves Fortune 500 companies.

Extreme claims to offer something close--a solution to the coding mind-set that a perfect product can't be produced quickly and that a quickly produced product can't be perfect.

Nuts and bolts
One of Extreme's key tenets requires programmers to release a nuts-and-bolts version of its product to the customer first and then continue to build additional features afterward. This immediately remedies the time-to-market problem, and customers wind up with a less buggy product to which features are added as the customer demands.

Extreme also requires programmers to maintain a direct relationship with the customer. Rather than packing a product with thousands of features, the customer can specify exactly what they want, and the programmer can focus on perfecting a few features.

Programmers must write tests for their own programs before they begin coding. These tests are used instead of an independent "quality assurance," or testing, group--a technique that will save time, according to Extreme's advocates.

During the coding process, programmers also practice a technique called re-factoring. This involves constantly working to simplify the code. By keeping code clean and defining things only once, programmers reduce the number of errors that must be addressed later.

For code writers themselves, one of the most striking differences is Extreme's requirement of pair programming. Once they switch to pairs, many programmers say they prefer it because the team approach can dramatically boost productivity and quality. Extreme also mandates communal ownership of all code.

Other methods
Extreme isn't always the answer, though.

Beck has said the method works best with groups of two to 10 programmers, a size that fosters good face-to-face exchanges and direct verbal updates. Projects that are contained to a small geographical area are also better-suited to the requirement for pair programming. And government projects, which often require extensive documentation, must at least supplement Extreme's face-to-face communication with a paper trail.

Despite such restrictions, Extreme's advocates say it's changed their work lives.

"If no one is watching, I'll get lazy, (do) cut-and-paste programming, no test writing, no re-factoring--the sort of anti-patterns that make software suck," Extreme programmer Lyle Hayhurst said via e-mail. "If someone is watching me, I'll probably feel guilty and do the right thing."

Jack Bolles, a technical team leader at Chicago-based ThoughtWorks, concurred. "I feel like I get better work done--and more work done," he said.

Over the years, programmers have developed other methodologies to help organize software development. In the Waterfall method, for example, companies lay out in advance all the features that will be included, assign tasks to different people, and then begin coding. An integration process follows at the end.

"It assumes that your customer knows what they want up front, which they never do. And if your customer changes their mind, it's a big problem," Larson said.

Extreme Programming, by contrast, advocates adjusting and building onto products throughout the development cycle. It also uses an ongoing strategy of collaboration and face-to-face contact. It is the human interaction--even in the cold, calculated world of software programming--that ultimately makes the methodology a success, Jeffries and others said.

"It's a lot less lonely than solo can be," Extreme programmer Steve Freeman said. "Sometimes you just get stuck, and that's really lonely. It can take some effort if you don't know what to do next. It happens a lot less with a pair. And at least there's someone else who understands the problem."