WIRED ON FRIDAY/From Silicon ValleyWard Cunningham is bearded, tall but plump; Kent Beck is balding and stalk-like. Beck dances around a stage, peppering you with a buckshot of ideas and ad-libbed catchphrases. Cunningham sits you down in the corner of the room, asks after your health and quietly talks about the meaning of his famously beautiful code in considered tones.

Their work together on Extreme Programming has spawned a shower of books, megabytes of vicious online debate and changes in the way dozens of companies large and small create software. But when separated, and asked to describe the genesis of the idea, they constantly ask if the other's story matches their's. It does - although they say it in very different ways.

All along, there seems to be a slight tone of amazement that they've managed to work together at all - an amazement that seems rather at the heart of the shock cure they prescribe for the flailing world of corporate development.

Because the idea that Beck and Cunningham can work together is nothing compared to the unlikelihood that management and software programmers can produce anything without killing each other, the project, or the corporation they work for.

It's true: after half a century, no one knows how to manage large software projects so that they ship on time - or, indeed, ship at all. The failure rate for developing software made for internal use, rather than bought off the shelf, is close to 70 per cent.

Some estimates put it closer to 90 per cent. And for every mission critical software project that goes off the rails, there's a company whose very existence is put at risk.

In the 1960s, this ongoing statistical disaster was ascribed to programming's lack of rigour compared to other, more mature technical skills, like engineering. But as layer after layer of sadistic rules have been created for creating programs, carefully documenting requirements, and meticulously plotting every detail of the schedule before it happens, the delays have merely got longer, and the failures more spectacular.

It's no accident that one of the best-selling books for programming professionals is called Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects.

It's a depressing world that Kent Beck knew all too well. He's spent time in every kind of software company - from Apple to financial corporations to his own software house. He's also seen endless projects fail. It was on one such death march - working on a payroll system for Chrysler motors - that he managed to persuade the management to junk all the traditional ideas, and go instead for a handful of principles he called Extreme Programming.

"I wanted a name that would be unattractive to the right people," says Beck, seven years on. "I wanted a name that Rational (one of the companies behind the more rigorous planning methods) would never support.

Part of his scheme was based on his earlier work with Ward Cunningham, a widely respected coder. "I'm a poor programmer, compared to Ward," Beck says. "But we worked out a way that didn't matter."

"When we worked together, we shared the computer," says Cunningham. "So we both learnt as we went along. If one of us made a mistake, the other one spotted it. We took turns having ideas, and borrowing the keyboard from the other."

It was the first revolutionary step in Beck's masterplan: two programmers per computer.

Pair programming is staggeringly counterintuitive - almost repugnant - to most coders. Programming is, by long tradition, a lonely and anti-social furrow, and with most coders as idiosyncratic and different as Cunningham and Ward, seemed doomed to failure.

But it seems to work: studies at Utah University have shown that paired programmers are 15 per cent slower than two programmers working separately, but produce 15 per cent fewer bugs.

It was also one of the first times that a methodology had considered how programmers should work socially, rather than as cogs in a machine. Another of Kent's rules: don't work late. Obvious to everyone - except the millions of programmers who pull all-nighters to hit a deadline.

Extreme Programming wasn't just about putting coders to work and keeping them sane: Beck also worked on how to bang the opposing worlds of coders' and managers' heads together.

The biggest problem that Extreme Programming tries to solve, says Beck, is "the difficulty of measuring the intermediate states of a project".

So he invented the Planning Game, where management and programmers work together to come up with a set of story cards, containing the goals of the project. By the end of the game, the combined team has broken down their needs to a stack of tasks.

Each one has an estimated time to complete by the programmers.

If there are too many tasks for the number of weeks in the deadline, the deadline has to be extended - or some of the cards dropped.

As it turns out, managers and coders seem to benefit from the game. Rather than spending hours slaving over requirement documents, the business can indulge in their wildest dreams and get instant feedback from the coders (the programmers can never say something can't be done - they can only estimate how long it might take).

And the coders like it, because they're never stuck with an unrealistic deadline. Everything is broken down into simple chunks that need just a few days to code and test. And a test for every task is written by the paired programmers before they code it up.

Another strange reversal for programming projects: usually coders write the tests after they've coded up the project, if at all. Too depressing, says Beck: write them first, and you know when you've succeeded, not when you're failing.

And it's also a way that the customer can check on your progress. One of the great problems of managing a software project, says Cunningham, "is the need to excel in dimensions invisible to the customer".

Testing lets the customer have proof that you're doing what they want you to do, while letting the programmer get on with the magic behind the test.

Extreme Programming turned the Chrysler project around, and is now practised at Ford, IBM - and at Dublin's own Iona. Its ideas have spawned a whole generation of new approaches to coding (called "agile methodologies").

Meanwhile, Kent and Ward are already working on their own next generation. For Beck, ever practical, it'll be the successor to Extreme Programming - an even way of producing excellent business software. Cunningham sounds a little more ambitious: "I want software to become a means to creating public art," he says, enigmatically.

But then, might they not be saying the same thing in different words this time too?