Slashdot Mirror
Single Sourcing: Building Modular Documentation
Scott Abel writes "Kurt Ament has hit the nail on the head! His latest effort, Single Sourcing: Building Modular Documentation is a valuable reference for those of us who seek to save time, effort, and money by implementing a productive method of creating information once and reusing it often." It's not a big book -- just 246 pages. Read on for Abel's brief review.
Single Sourcing: Building Modular Documentation
author
Kurt Ament
pages
246
publisher
William Andrew Publishing
rating
10
reviewer
Scott Abel
ISBN
0815514913
summary
How to build modular documentation you can re-use in different formats for different audiences and purposes
Ament covers the issues -- step by step -- that many others only discuss. He lays out a simple roadmap, complete with real world examples that have worked -- or not worked -- for his clients.
In Chapter 1 (About Single Sourcing), he carefully defines "single sourcing" and explains related concepts (reusable content, modular writing, and assembled documents) in ways that are easy to understand and free of techno-jargon. And, he does us all a big favor by addressing the negatives associated with using technology to assemble documents by explaining that it actually takes more creativity to write content that can fit into multiple media, for multiple audiences, than it does to continually rewrite information over and over again each time it is needed.
Chapter 2 (Building Documents) and Chapter 3 (Structuring Content) are of particular value to those seeking to understand the shift in thinking required to master single sourcing. Writers, programmers and managers will all benefit from these chapters. Each chapter is packed full of tips and examples you can begin using today!
Chapter 4 (Configuring Language) explains how to "configure" your writing to support and increase usability while Chapter 5 (Leveraging Technology) touches on issues including conditional text, conventions, localization, translation, variables and more. As are the previous chapters, Chapter 5 is written in clear, concise language and is not a chapter business types should skip. In fact, it's just the opposite. Managers and decision makers need to understand the concepts explained in this chapter because many of the benefits a single source strategy can deliver are made possible by combining good planning with the right technology. And, while this chapter is certainly not about selecting software tools, the author helps his readers understand some of the issues they will need to understand as they begin thinking about their strategy and the types of functionality they'll need to support with the tools they select.
What I like most about "Single Sourcing" is that Ament went straight for the meat of the issues. He doesn't belabor points or confuse the reader by jumping back and forth from subject to subject (as so many poorly written IT-related books do). Instead, he supplies us with a book you can read in an afternoon and use the information contained within the next day at work.
But, be forewarned. You're going to want your sticky notes and your highlighting markers nearby. Chances are you'll be using them a lot!
In Chapter 1 (About Single Sourcing), he carefully defines "single sourcing" and explains related concepts (reusable content, modular writing, and assembled documents) in ways that are easy to understand and free of techno-jargon. And, he does us all a big favor by addressing the negatives associated with using technology to assemble documents by explaining that it actually takes more creativity to write content that can fit into multiple media, for multiple audiences, than it does to continually rewrite information over and over again each time it is needed.
Chapter 2 (Building Documents) and Chapter 3 (Structuring Content) are of particular value to those seeking to understand the shift in thinking required to master single sourcing. Writers, programmers and managers will all benefit from these chapters. Each chapter is packed full of tips and examples you can begin using today!
Chapter 4 (Configuring Language) explains how to "configure" your writing to support and increase usability while Chapter 5 (Leveraging Technology) touches on issues including conditional text, conventions, localization, translation, variables and more. As are the previous chapters, Chapter 5 is written in clear, concise language and is not a chapter business types should skip. In fact, it's just the opposite. Managers and decision makers need to understand the concepts explained in this chapter because many of the benefits a single source strategy can deliver are made possible by combining good planning with the right technology. And, while this chapter is certainly not about selecting software tools, the author helps his readers understand some of the issues they will need to understand as they begin thinking about their strategy and the types of functionality they'll need to support with the tools they select.
What I like most about "Single Sourcing" is that Ament went straight for the meat of the issues. He doesn't belabor points or confuse the reader by jumping back and forth from subject to subject (as so many poorly written IT-related books do). Instead, he supplies us with a book you can read in an afternoon and use the information contained within the next day at work.
But, be forewarned. You're going to want your sticky notes and your highlighting markers nearby. Chances are you'll be using them a lot!
Other resources:
- Kurt's site: http://www.infotektur.com
- Book site: http://www.infotektur.com/books/singlesourcing/ind ex.html
Scott Abel (abelsp@netdirect.net) is a content management strategist who assists his clients in planning and preparing for content management initiatives. Scott is a frequent presenter at industry and professional service seminars, an instructor at Indiana University Purdue University at Indianapolis Community Learning Network, and vice president of the Society for Technical Communication (STC), Hoosier Chapter. You can purchase Single Sourcing: Building Modular Documentation from bn.com, though new copies are currently out of stock. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
That way you have documentation, not docucucucucucucucucucucucuumentation.
Because of design by contract the code is pretty much self documenting.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
This would seem to be more of a reason to avoid modular doco. Creativity is not, shall we say, plentiful? at the typical workplace. And often, it isn't wanted when it is available.
Aptal soru yoktur; sadece merakli aptallar vardir.
./configure --enable-mod=ambigeous
make
make test
make install
It seems that no matter how much I spend creating documentation, the users of the system don't use it, don't know how to access it, won't use it.
I say take your money and buy a book on user interface design. The problem is not how well written the docucumentation is; it is the fact that we NEED the documentation.
Open source development is my way of competing with the low-cost programmers in India...
One thing I've noticed over the time i've spent surfing is that most online content has to get straight to the point with as little fuss as possible. If an article can't capture the interest of the reader within the title, or follow up within the first few sentences, people often quit reading and move on. I actually wonder how many people RTFA in slashdot.
Very different from books, where the author is more able to exert without much fear of whiplash...
use XML. provides re-use of content. no big deal. and now there are collaborative XML editors, which allows authors to work on various sections of the same document.
Consensus is good, but informed dictatorship is better
In a similar vein, Scott Abel has demonstrated how to use the same review for multiple audiences.
Why not just submit a link, Scott? Sheesh.
is this just literate programming warmed over?
my main complaint with literate programming is that the source can quickly become unreadable (or, requires a different mindset to read it).
....using Maven's xdocs, you can generate both HTML and PDF docs from the same XML source file.
We use this on GForge and it works pretty well....
Tom
The Army reading list
This was my genuine review in a year where I was the person to go to, to pull projects out of the fire...
"Productivity, marginal. You get a lot done but you keep wasting time by writing documentation. So I've given you a marginal to reflect that."
Teach me to work for a major games company.
I guess we've all gotten used to artificially inflated monster technical books, where it's expected that Learn Java 2 in 24 Hours needs to be 950 pages or it's crap.
Here's a clue: Those big books are hugely padded by:
1. Large margins so there can be a little note every few pages.
2. Repeated program listings, also with huge margins.
3. A hundred or more pages of fluffy introductory chapters ("What is a programming language?").
4. Massive redundancy.
Personally I'm waiting for the return of slim, readable books.
If you've ever used a program called InterLeaf you will understand that this is what publishing is all about.
You create a content object and add it to your content library. Then, wherever you need that object, you point at it in the content library.
For the HTTPd minded - it's the same idea as SSI.
My office has been taken over by iPod people.
The only thing this left out: what the hell is Single Sourcing?
The editors own and love this book. Just look at all the dupes posted. Same info again and again... (and in some cases, again and again...)
I think that a lot of this information is aimed at documentation professionals (technical writers, content strategists, knowledge management system workers, there are a lot of titles) who are very creative and love to work with these systems, rather than analyst/developers who view documentation as an evil waste of time.
From personal experience, I know that it's not that difficult to mark text as "internal use only" so the developers can quickly find the names and values of parameters and "end user only" so that users who actually use the compiled system can see what the different options are.
I think that the issue is less of "creativity" than it is of thinking through the issues and handling them consistently.
Even if I have quite a few books on computer science, I still use www much more. It has far more than 246 pages and is near fully indexed through Google. And, cut'n'paste makes my life much more easier.
Paper is near passé.
And, new topics like this is often extensively referenced at popular sites like Slashdot; do yourself a favor and check it out!
I remember providing input to a tech writer, then red-lining the first draft to the point that rewriting the entire document seemed necessary. While I would rather write PHP or scripts, there is no one who better understands code than its author.
Today's on line documentation provides a variety of methods for an engineer to provide documentation. Such examples are:
How to's and Mini How To's
FAQ
Web page with screen shots
Forums and Blogs
That being said, I am reminded of a conversation with Clyde, a retired avid sailor, who talked about stories in "SAIL" magazine. "First person stories written by sailors usually suck!" he said. "Give me an article written by a professional writer. They're easier to read."
It's easier to write documentation than to try to tell someone what to write. ....Now if only I can break away from coding long enough to read this document on creating documentation.
This review was stimulating, and filled me briefly with hope, then I crashed after pondering a bit. I'd like to think that we could look back on this someday as a turning point of some sort, perhaps the foundation of a new engineering discipline of documentation. Of course, lots of people thought (and probably still do) that SGML was the foundation and now we're building walls. And maybe it was, but SGML (and the derivatives HTML, XML, and future arbitrary useful DTD to come) suffer from some problems - external and cultural mostly. The technologies are somewhat complex, and there is a general lack of understanding about how to apply the technology to advantage.
The core concept of arbitrary display and formatting of structured text, which appears to underly this new work, remains alien to most of the people making business decisions and authoring documents. When you combine a vacuum style lack of good tools to author documentation in the target technology with a flood of readily available "old paradigm" authoring tools for making stuff look pretty (word processors and desktop publishing stuff) you get the explosion in documents that was seen in the 90's. You also get the tremendous resource drain as these docs are updated and reformatted for subsequent generations of word processor formats that continue to mix content and presentation. We also see a direct parallel problem with the amazing fanatical market success of programming environments where logic and presentation are mixed (MS.asp, PHP, etc.) over object oriented tools. Far, far more dynamic web sites are built "the old fashioned way" despite the availability of decent, even "better" authoring tools that exist in the object oriented world.
Unfortunately most organizations that produce and use documentation do so as an aside at best, or an afterthought at worst. Organizations typically don't value documentation highly enough to create job descriptions for skilled technical writers. Corporations with IT staffs of hundreds of people - managers, systems administrators, help desk workers, developers -- often don't have a single Technical Writer.
Take the help desk as a primary example. Just about every big company produces volumes of documentation for use by the help desk workers. Sadly, much of that documentation is created after the fact, by desperately struggling front line help desk workers themselves, who randomly try to assemble facts and myth about problem resolution. The folk creating the systems are generally not given sufficient time to develop and maintain documentation, often barely enough resources to develop the system in the first place, before moving to the next task. It's rare for companies even to realize the blatant "in your face" opportunities to save money by investing in better documentation.
If we can't get developers to understand this basic concept, how can we get front line help-desk workers who are writing documentation for themselves out of desperation and under the clock of "you still gotta answer twenty calls an hour and resolve 19 of the problems before hanging up"? Even better, how do we get a bureaucratic organization to invest in skilled technical writers?
It seems to me that to get to this point we will need to create authoring tools that are so powerful and easy to use that the authors of documentation don't need to think about the separation of content and formatting -- it "just happens" in the background. Anybody who writes such a tool gets to spend the rest of their life retired on a beach, earning twenty percent and drinking rum from hollowed out pineapple shells with little paper umbrellas in them.
Things should be made as simple as possible, but not any simpler. -- Albert Einstein
That added a lot.
YOU FAIL IT!
RUP Link
Also, the cobination of SoDA, Rose and Requisite Pro offer a lot of options for manipulating requirements and code documentation.
ReqPro Link
(If this seems like an ad... I work work for IBM Rational.)
What you've just described ("authoring tools that are so powerful and easy to use that the authors of documentation don't need to think about the separation of content and formatting") has been the holy grail for development/documentation teams for a number of years now.
But earlier, you called for an investment in skilled technical writers. The fact that you even remember when a tech writer was assigned to every project (mostly because the mainframe programmers had no time or skills for such nonsense) should be a hint that those days were in a golden past. Tech writers, graphics developers, trainers, and so are are fast disappearing from all but the largest companies. Because of the ease of use of many development/design tools, all of us are expected to be analysts, designers, developers, writers, trainers, and maintenance men. Tools, such as XML that allows single-sourcing of documentation, is another step toward the combining of roles and the disappearance of another antique role.
The whole challenge of single-sourcing isn't in which technologies to use, but the integration of these technologies, the process by which content is produced and the interaction between content (knowledge) producers.
For example, at my last company we wrote software products. Document engineers would typically take one of the (almost) finished products and start writing documentation from scratch. Technical information that was already stored in programs, on wikis, in configuration files, etc.. was duplicated in the official documentation. The results were mixed- although the documentation engineers were very professional and diligent, all sorts of inaccuracies crept in.
How do you produce documentation without any duplication? That's a real challenge. XML is part of the answer because you can automatically transform XML information into a publishable format. But no company has all their technical information in one place, in one format. Scripting languages and literate programming are also part of the solution. But the challenge is in getting the collaboration between different people from different departments to work.. Changing the organizational culture from the lazy habit of copy-and-pasting information to the stop-and-think habits required for single-sourcing.
Such a zero copy-and-paste organization is really hard to achieve, well done to the author for addressing this issue.
I would find these reviews a lot more useful if there was more disclosure of the reviewers biases.
How do I know the author isn't benefiting from writing his glowing review here in some way? I'm not accusing the reviewer of any misbehavior here, but when the only negative of a book is that "But, be forewarned. You're going to want your sticky notes and your highlighting markers nearby" I have to question the bias of the reviewer.
Sample review checklist
1. Have you contributed to this book or been cited within the text?
2. Do you have a personal or business relationship with the author(s) or publisher?
3. Do you sell services related to the books topic?
"Honest officer, I was just eating a can of pringles and I thought, 'Hey! Maybe someone provides free internet service outside this large office building!'"
"Everything you know is wrong. (And stupid.)"
Moderation Totals: Wrong=2, Stupid=3, Total=5.
It's a games company; naturally they're going to be peeved if you go writing all this helpful documentation and ruining all the fun. By the way, that kind of thing is called "cheats", not "docs" in the gaming business.
Too many engineers look at tech writers as clueless English majors, useful only for cleaning up spelling and grammar. Or arrogant, burned-out former programmers who think they know everything, and really know very little. True, there are a lot of tech writers like that, and their product is not worth reading -- assuming anybody can read it. But there are also serious, motivated tech writers who know a lot about communicating technical subjects.
I like to think I'm one of those. I'm biased of course, but I have been told, more than once, that nobody understood how a product or technology really worked until I sorted a huge pile of random facts into a useful form. (This is especially nice to hear when it comes from the people who designed the system in the first place!) I'm probably not the best in my field, but I think I earn my pay. (Well, no pay right now, industry slump y'know. Oh well.)
Of course, not all documentation really needs a tech writer. You sound like you mostly write little end-user apps. For those, I agree, a good GUI is more important than a good manual.
But consider my own specialty, the API manual. How many of those have you seen that don't make you scream with frustration? Writing good API docs is hard. (Lotta fun though, at least for a compulsive nit-picker like me.)
And writing isn't as hard as maintaining. My last job involved a development framework with more than 10,000 APIs. Which was maintained in RTF. (Please don't laugh, it's not funny.) And which had to be single sourced for four different product targets. (Windows and Linux, two different programming languages.) And, oh yeah, my boss thought that version control was a silly idea.
Why was this documentation base such a mess? Because at this company, the "nobody reads the docs" mentality prevailed. Even the writing team was infected with it. And this self-fulfilling cynicism really hurt the product. The API has a reputation for being obscure and hard to use. Whereas it's really pretty elegant, and even easy to understand, if properly explained. In this case, bad documentation is doing a lot to consign a superior product to undeserved oblivion.
I should end with that pithy comment, but I have to drag the discussion back ontopic. Because of the company's indifference to doc issues, they're only now converting the documents from RTF to markup, something they should have done 10 years ago. Alas, the project is headed up by an intelligent but technologically clueless individual who thinks a little XML transform experience makes him an expert on content management. (Sour grapes? I guess. Then again, I did recommend hiring the guy.) Last I heard, the project was months behind schedule, and was close to being in deathmarch mode.
So I'm deeply interested reading Ament's book. Maybe it'll be useful on my next job. But even if it's well-written, I don't think I'll enjoy the read. Too many lost opportunities.
- There are no affordable off-the-shelf content managment for most technical documentation apps. Yes, there's a lot of content management software out there, but it's either specialized in some other area (mainly web applications, 'cause there's a lot of money to be made there) or it's a general-purpose CMS platform that takes a lot of work to adapt to a particular purpose.
- There are lots of XML editing products out there, but few of them are serious products. Some dweeb combines a Java editor component with an XML parsing engine, and behold! A collaborative documentation tool! Not that easy.
- Retraining writers to think in XML terms is a bitch.
- XML production tools are still pretty immature. XSL-FO will probably stabilize soon, but I wouldn't rely on it yet.
Eventually, XML will take over. But it's gonna be a long, painful transition.XML-specific databases are very intriquing. Many have impressive feature sets. But it's still a work in progress. There's nothing out there you can buy and use without spending a lot of time adapting it to your specific project. Even without license fees (usually pretty high) the up-front costs are huge. Try getting your boss to approve spending a lot of bucks on a product with no track record!
A few solid products are beginning to appear, but they all have serious limitations. I'm really taken with XMetal, but it only runs on Windows. (Even if you're not an open source zealot, you have to be cautious about a product that won't run on the platform your engineers use. Anyway, XMetal now belongs to Corel, which is busy imploding.) XMLSpy is powerful and cross-platform, but its editign features are clunky. FrameMaker 7 is OK (assuming you don't totally hate FrameMaker's primitive GUI), but creating or modifying an XML application for it is a nightmare. And there's really nothing else.
Blockquoth the poster:
You're right -- but it takes a LOT more than that to produce clean, usable documentation. And yes, I speak from experience; I've been a technical communicator for more than eight years, and I've spent the last two years just cleaning up existing documentation written by programmers.
The problem I've found is that programmers tend to write documentation the same way they write code: they see a project as an assemblage of individual features and widgets, and they put most of their effort towards ensuring each of those features works correctly. The fundamental concepts that tie the features together into an application are largely taken for granted.
As such, the documentation these programmers produce is technically complete and accurate but almost completely nonsensical from a real-world user's point of view. There's no unified flow or top-level view. The user is basically expected to already know what they want to do, so that all they need to do is look up how to do it.
That's why I don't trust these efforts to make documentation "modular." It's impossible to develop a coherent narrative in such a format, and you can't really educate the user without that narrative.
Actually, it's a reason to not go plunging willy-nilly into a modular doc project.
Yes, it takes a bunch of creativity and up-front effort to pull it off. But the payoff comes when it's time to put out a new version of a large doc set, or if you have to publish in multiple formats. We have a system we developed in-house (using Framemaker as the foundation) that we can use to pump out printed manuals, PDFs, raw HTML, compiled HTML (.CHM), and Windows Help, all from one set of source files. We could do other formats (RTF or raw TXT, for example) with minimal effort.
But if you're doing a one-off doc, you're probably better off to just crank it out.
------ "Darn floor. Big bite." (Koko the gorilla's best attempt at explaining the experience of an earthquake.)
DocBook is cool. I'm writing a book using it. But it's not the format for all technical content. If you're writing your basic mass-market computer book, or the web equivalent, DocBook probably has everything you need. (Though the markup for the official DocBook reference is forced to use generic tables to list element parameters -- there's no specialized element!) But I'd hate to use DocBook for a big API document base, especially one where single-sourcing is an issue. IBM's DITA framework is immature, but looks promising.
But embedding all your documentation in your source code is a very bad idea. That's the concept behind JavaDoc, and I have the bruises to show how badly this works in practice. Writers and programmers tripping over each other. Programmers that don't know how to write markup or even prose. Writers that have to branch the source code tree because the main tree is frozen. There's more, but I'm beginning the have post-traumatic flashes!
The solution I'd love to see is a tool that merges the embeded-comment docs with the full user docs. This would not only eliminate the problems of JavaDoc, it would flag inconstencies that happen when programmers don't keep the writers up to date.
or Troll... really.
Always nice to hear from you!
I say take your money and buy a book on user interface design. The problem is not how well written the docucumentation is; it is the fact that we NEED the documentation.
Because if only the hundreds of commands for which I maintain man pages had a decent user interface, those silly documents could finally be abandoned.
Then I could move on to more important tasks, like posting inane comments on Slashdot.
Comments like this one.
Sorry, I've seen first hand "single sourcing" hard at work. It's the biggest boondoggle since the "synergies" of the late nineties.
Writing good documentation is hard work. It seems to me that the only people who benefit from "single sourcing" are the people who are writing these books and giving overpriced lectures to rooms full of unemployed tech writers.
Ultimately it won't improve the clarity or usefulness of your documentation. It won't provide you with the ability to understand the subject or the audience any better.
Don't get me wrong, if there were a magic-bullet that single source claims to be, I'd be all for it. It would be nice not to have to worry about document formatting. But personally, I think it's simply another way for organizations like STC (The Society for Technical Communication) to filch money from their members.
Notes From Under *nix: blas.phemo.us
They know the product (code or hardware) so well that they forget some of the preliminaries, and the stuff they produce is not task oriented. A cookbook produced by a similar method would have the titles for all the recipes listed together, all the ingredients in another place, all the mixing instructions together, all the cooking instructions listed together. Actually cooking something would require that you consult several spots in the same manual and hope that the title for what you picked actually had something to do with what you wanted to eat.
It's called "QuickSilver" now.
RUP is a development process framework. It's sold as a bunch of documents/templates/intranet stuff, at a pretty eye-watering price. What's a development process framework ? It's a way of saying "when you start a software project, you usually need to go through a bunch of stages. For each of these stages, we have templates/guidelines/documents blah to help you build non-code artifacts (project plans, requirements documents, release notes, the whole kit & caboodle). Customize this to your organisation/project by choosing the stuff you need - out of the box, the process contains over 100 "artifacts", so you probably want to leave some out - and you will have all the tools you need other than an editor, compiler and caffeinated beverage vending machine to create world class software.
If I were running a major software team for a large, sophisticated organisation with a lot of cash to spend, I'd definitely look for something like the RUP. It requires a significant investment of time, effort and money, but just deciding how you're going to build software is a cathartic process, and it flushes out all the views people hold explicitly, rather than finding out halfway through that Fred doesn't believe in source code control, and Sue only works from CRC cards.
Check out "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition)" for a concrete example of how the RUP is applied - it's a lot more useful than the brochure-ware "books" I've seen.
It's all very well in practice, but it will never work in theory.
I benefit from single sourcing. No, it doesn't directly make my books more effective, but it does mean I spend a little less time replicating changes all over the place, so I have that much more time to spend on more direct improvements to the books.
It's not a "magic bullet," and won't even help at all in certain situations. But if you've got a lot of similar books with slight variations, and output them to multiple formats, single sourceing will help keep you sane.
How is this post flamebait?
.texi files.
The guy could have been less sarcastic, but his point is germane.
For program documentation, the GNU Texinfo format is very nice. It generates Latex (to which the converters he mentioned can be applied) and also HTML, info, and PDF from a single source.
I don't know of a way to handle internationalization with it, other than to have multiple
The thing about "single sourcing" is that people have been doing it for years. It's just never had the high-prestige and high price tag that it has today.
My beef is that there's minority groups in the overly influenced world of tech writing that have convinced many others that "single sourcing" is a recipe that you can pay to learn at a three-day lecture, then go out and write great documentation.
In the majority of cases, what single sourcing turns out to be is a great waste of time and effort. In my experience, it's a pipe-dream for project managers who are otherwise too lazy to think through the ultimate aims of the documentation and how those aims are to be achieved.
I'll very much agree with you, the ideas that go into the buzzword, "single sourcing" are very helpful in creating varying document sets based around a core set of materials. The problem is, most of the time, documentation doesn't fit this model, and managers can't really deal with the extremely intensive and time consuming work up front.
Notes From Under *nix: blas.phemo.us
Andrew? Is that you?
You've reminded me of a conversation I had a very long time ago. I was going to a school that had no Computer Science or EE department. Programming was taught in various science departments (mostly Math and Statistics). I told somebody that taking Logic had helped a lot with my programming.
"What department is that in? Math?"
"No, Philosophy."
"We have a Philosophy department?"
Wikis are a lousy way to maintain technical documentation!
In order for technical documentation to be useful, it must be clear, complete, correct, and up-to-date. Wikis do nothing to insure these qualities. In fact, the best model for insuring them is a central maintainer (a person or a team). A central maintainer can also insure another quality missing from Wikis: consistency!
And what really suckjs is that it's not even a NEW boondoggle. I've been hearing about the promised land of single source documents for at least a decade. Anyone remember "Information Mapping" with its expensive seminars and rigid templates? Where are they now?
I am glad to see another emerging IT "area" in which all the tools and consultants can be replaced by a set of simple Perl scripts.
(pod2man, pod2html, etc.)
"Life is life." --Laibach