Ratio Closing Question

From the CritiqueOfXp:

Suppose you decide to try ExtremeProgramming on your project, and six months later, you decide that the approach isn't meeting your expectations. Nothing is written down - there are no architecture or design documents and the only knowledge of the project is in the heads of the developers. What do you do?

Well, since the knowledge is in the heads of the developers, could you have them write it down? -- AnonymousDonor

I'm confused as to why this is a big deal of a question. I have yet to visit a project where the documentation is up to date. So what you do is what you would do on any project - you set out to create some amount of documentation for the legacy. How much and how accurate depends on everything it always depends on. Why is this question less than obvious or what am I missing in the question? -- AlistairCockburn

However, after six months, if you have been doing XP, you'll have a running system full of UnitTests and FunctionalTests, correctly doing a known amount of the most valuable things the customers asked for. Wouldn't you have known a long time ago, since you did WorstThingsFirst, that you were in trouble ... or wouldn't you not be in trouble? -- ChetHendrickson

The critique attributes beliefs and practices to XP which are not part of it, and then ridicules those straw men without evidence. It's very well written. -- A handful of people who have tried XP.

And this is somehow opposed to ExtremeProgrammingExplainedEmbraceChange? It's full of StrawMan arguments too. My favourite example is in chapter 1. Sentence 2. "Here are some examples of risk." Lists some (but not all). Then lists XP responses to those risks. In Our Mission, "What we need to do is invent a style of software development that addresses these risks." As in, only those listed. There are other risks like the system may need to be cold started ten years later with a completely new team. However, the book goes on assuming those are the only risks.

I think the only methodological book I've read that systemically supported its arguments with empirical evidence and rigourous argument was CodeComplete. (I haven't read SteveMcConnell's other works)

XPXEC is successful because it is a manifesto, as KentBeck once called it. Manifestos are chiefly rhetorical. I suppose it would be possible to argue XP rigourously, but that would likely be ineffective as a communication device.

I suspect the ExtremeUnifiedProcess gives one answer to the closing question. Essentially, it says to do XP, but also do analysis as it's needed, and then use the tools that suit you, including use cases where they help. The benefit in this is you never do more analysis than you need, and you always do as much as you need. It's not "tossed"; it's integrated with your iterations. It's not absent from the start of the project either; it's just whittled down to not more than you need to do your spike. -- PeterMerel

Peter- You said, "...do XP, but also do analysis..." I'm sure you didn't mean what I read in this statement. -- KentBeck

Analysis is what the SP guys suggested you "tossed". I don't actually agree you have tossed it but I can see stuff that most folk call analysis that you replace with an iterative process. I don't think you could directly leverage this iterative process to work things their more traditional way.

What stuff is "tossed"? I think it's stuff about modelling the problem domain before you try to model a solution. I think XP does that iteratively through the art of breaking UserStory(s) down into EngineeringTask(s). One of your more marvellous insights in XP is that it's better to break down requirements into small functional threads than to try to analyze them into large logically-associated packages. Once you have a CommitmentSchedule in terms of UserStory(s), it's almost a trivial step to take one iteration's UserStory(s) and do a task breakdown/detailed design for them.

But to move back from XP to the world of RUP and SP you'd have to junk these stories. You'd have to be able to develop by subsystem. You'd have to treat the requirements as a big problem. You'd have figure out what you're gonna need. You'd have to break the big problem down by analyzing it into a bunch of (likely UML use case, class & sequence) diagrams that map an almost platonic space. You'd have to figure out where your system fit in there. Then you'd have to define subsystems, trying to make certain they're as complete and consistent as you can on paper. You'd have to do enough of this sort of analysis up front so you could at least imagine you could integrate at the end of the project without the benefit of any iterative tests & spikes.

XUP might be adapted to do that. XUP basically says stick to XP as closely as you can, but where people (managers, external overseers, ...) want to look at what you're gonna need, let them play with RUP. So if you wanted to do what these SP guys want to do - use XP but have a way out - then XUP would let them second-guess themselves using their preferred analysis artifacts. That way they'd have what they thought they were gonna need when they somehow resolve to junk XP. -- PeterMerel

Sorry. I was hungry. -- RonJeffries

In what sense does the closing question address a need for analysis at all? It clearly states that the knowledge of the project is in the heads of the developers. HowDoYouGetaDocumentInXp?

The premise is simply false. XP projects generate stories, CRC cards, legible source code and two kinds of tests -- and those in abundance. In addition it doesn't keep any out of date documents or code, so there is no misinformation kept. The fact that the programmers try to keep all of the knowledge of the project in their heads does not prevent the knowledge from existing anywhere else. -- PG