Excerpted (without permission from author Phlip) from comp.object:

Someone - no idea exactly who - writes a huge spaghetti-code Win16 program using the Cascading Dialog Boxes Anti-Pattern. The user claws their way thru dialog after dialog, mostly working blind, until they clear the last one and get a beautiful output. To edit this they have to back-track a number of dialogs, change stuff, and roll-forward again. Also blind. The CDB Anti-Pattern is /very/ closely related to the Show The User Our Private Object Model And Nothing Else Anti-Pattern.

I'm charged with replacing the UI with an OCX wrapper. We'll create a new UI (in glorious VB, of course) that drives the OCX, which then paints the program's output into a rectangle on the main app - not floating loose in its own crummy Win16 frame window.

Can't touch the spaghetti - it does a doctoral thesis worth of complex math in there.

In the ODL for this OCX, I create one function for each dialog box from the Win16 app. Each argument to each function is named exactly the same as its origin on a dialog. This enables me to plug the function in right where the dialog box used to plug in. Very little research needed; just searching the code for comments that the original authors copied out of their dialogs.

Result: The last-version user-documentation, and user-interface, is now the programmer-documentation for my OCX's interface.

Next, I copied that documentation, and the results of all my research into the Pasta Zone inside this mono-object, into big fat comments in the ODL file.

Next, I used TallTree's DocJet to translate these comments, with their functions and parameters with them, into a Web site, including excuse-free index pages.

Next, nobody except me ever used the OCX. I wrote the VB UI, and of course I gave it a real Editor UI-Pattern, where the user always sees results, and can change any config variable at any time - my VB takes care of the mechanics of calling all those dialogs to always produce output.

So no coders except me ever read the Web site I painstakingly built. 

Then the user-documentation writers direct their attention to my product, and they start nickel-n-diming me with questions like "The option 'Grid by Linear Dip Projection' on the second tab: What's that mean? and why does that make all these other options visible when you turn it on?"

I tell them "uh, could you point your Web browsers at this URL here before asking me anything?"


''Ummmm, and the challenge is?''

Don't look at me. It was just an anecdote for "literate programming to the rescue". An ExtremeProgramming team would have instrumented the legacy code with unit tests, applied "ExtractAlgorithmRefactor" to build an AcceptanceTest, then ripped it all up. I wasn't a team at the time ;-)  --PhlIp.
----
See ExtremeProgrammingChallenge