"Another ancient subject that seems to be popping up again is the idea of modular document creation. This is one of those concepts that comes through about once a decade, seduces all the writing managers with the prospect of greater efficiency, takes over entire writing departments for a couple of years, and then falls out of favor as people finally realize that document reuse is not a solvable problem in document delivery but rather an intractable problem in document writing — which is, how to retain any sense of logical connection between pieces of information while writing as if your target audience consisted entirely of people afflicted with ADD.
"I could go on at length about this, but instead I'll simply leave you with the observation that my personal love affair with modular documentation occurred in 1978 and that I haven't seen a thing since then that would change the conclusions I reached about it almost thirty years ago. This is not to say that I'm trying to discourage the technical writing community whence I came from their enthusiasm for the modular authoring technology du jour, since engagement in such efforts is virtually guaranteed to buy tech writers a few years in which they can act like software engineers and present themselves as engaged in cutting-edge informational technology development rather than plain old technical writing. That strategy has worked great for some of us."
I think I have reasons why DITA is different, but wish I had more details on the failures Jon has seen over the years. Can we explain why DITA is not just the modular documentation du jour?Experienced writers will recognize the three information types - concepts, tasks, and reference - as the three great user manuals of the golden age of software, when you did read them in order. Apple called them Learning X, Using X and the X Reference. My first tech docs were the user manuals for my MacPublisher, which shipped in the year of the Mac, in English, French, German, and Italian. To this day, many O'Reilly books follow the triad of Learning X, Programming X, and X - the Definitive Reference. Minimalism has moved the primary documentation focus to the practical "how-to" kind of knowledge we discover by user and task analysis. Today's impatient users are not so interested in learning the theory and overview, they want the instant gratification of problem solutions.
Who at IBM (if anyone takes credit) named it Darwin? How clearly did it borrow from Object-Oriented Programming, etc.?