Extreme Computer Science

Premise:

When doing Computer Science one is by definition breaking new ground. The code one writes will remain at the core of a system for its lifetime.

Examples: Perl, XML, TCP/IP, Linux, GNOME, Deep Thought.

When developing non-groundbreaking applications, such as typing a zillion Business Rules into a data warehouse, one is by definition _not_ breaking new ground. That means any analysis or design will return the result "this is a Business Rule. Type it into the rule system with the rest."

Examples: Every dumb-ass Web site you ever hit.

While doing Application Development one _avoids_ research. The code one writes will _not_ remain at the core of the system forever. That's the database or object repository or library that you Bought Not Built.

If your problem space is indeed so hard that you are researching, not just "translating requirements into features", then you'l need to change the standard XP rules a little.

--PhlIp

Problem:

Who in Computer Science gets the role of OnsiteCustomer?

Hypothesis:

The customer is "Pure Science itself". This means the stand-in for that role is a mortal human who "owns" understanding of the science that the project aims for.

This proposal reveals that a UserStory, in this case, can be technical and domain-specific. Such as "The skip-lists must execute in OlogN time".

This is a slight departure from consultant-style XP, where User Stories represent interaction with a system. XP and XCS have different motivations behind the roles and artifacts involved, so they lead to different project by-laws.

A more pragmatic answer: The various players compete for this role via merit for each factor involved. --PhlIp