Benefits of tool diversity, part II

by Tom Johnson on Aug 7, 2014
categories: creativity • dita • technical-writing

In my previous post, Is tool fragmentation a good thing?, I lamented the trend toward tool fragmentation in the tech comm community, noting several disadvantages that fragmentation brings:

• fragmentation of community and knowledge sharing
• increased overhead of learning new tools
• frustration with HR departments who expect strong knowledge of their chosen tool (among hundreds)

I explored the appeal in having a standard method for tech comm that we can plug in to, becoming immediately proficient at our jobs. By removing the need to tinker with different publishing technologies, we could instead focus more seriously on the technology we're documenting.

Several commenters on the post contributed some insightful feedback. Bill Swallow noted that diversity is part of the tech comm landscape; tools may work in one situation but not in another. He said no universal approach will ever solve all pain points.

Mark Baker noted that the ubiquity of open source tools and platforms provide enabling technologies that allow people to more easily build tools. He said that he was able to build his new XML architecture, SPFE, by leveraging other free technologies (ANT, Python, Perl, Saxon, FOP). The proliferation of tools is partly because the foundation to build the tools is immediately available.

Mark also noted that new tools are constantly developed out of a company's need to "right-size" for the situation. In other words, the company has a particular need. The existing tools don't entirely meet the need, so the company either forks an existing tool to make it work for their situation, or they build their own, such as with Ponydocs, which is Splunk's fork of Mediawiki. Right-sizing is often much less painful than living with a limitation in a tool.

Part 2 of my analysis

Now let's enter part 2 of my analysis. Lately I've been listening to The Third Chimpanzee, by Jared Diamond. Diamond has spent ample time in Papua New Guinea (PNG) doing anthropological research. Although not directly related, Diamond's views provide a lot of support for the embrace of tool diversity.

Diamond says that almost no country is as diverse as PNG. Natives speak more than 820 unique languages and have startlingly distinct cultural practices from one group to the next. The geographical terrain is partly responsible for the cultural separation of groups. Apparently it wasn't until 1938 that outsiders first made contact with the Dani people in the Great Valley (deep inland). Explorers only spotted the group by plane. The subsequent trek inland past PNG's impassable swamps and jagged mountain ridges required the aid of some 800 porters.

Diamond laments the cultural transformations that have taken place among the PNG populations that were once separated from each other and walled off from outside influence. Beyond language differences, they had notably different rituals, beliefs, living arrangements, clothing practices, sexual practices, and more.

Given that cultures have made contact with each other and blended (an inevitable result from technological innovation that allows us to transcend borders), much of the uniqueness of the PNG groups has been lost. Diamond says that our general lack of isolation from each other marks the end of the possibility for different models of human living to be carried out.

I think we recognize the same loss of uniqueness when a franchise restaurant chain opens another store. About a dozen years ago, I spent 2 years in Egypt teaching English. I was saddened to see, on my first day, 3 American chain restaurants right next to The American University in Cairo: Kentucky Fried Chicken, McDonalds, and Domino's Pizza.

The more we integrate with each other, the more we tend to lose diversity. And with less diversity, we also lose innovation and the possibility of trying out different models of human living.

Diversity is something that is strongly sought out in software companies in Silicon Valley. The lack of female programmers troubles software companies. Software created mostly by male mindsets leads to a homogeneity of thought and lack of imagination and empathy for another audience. Diverse engineers build better products.

At my previous job in Utah, there was very little diversity among the workforce. Sameness of thought, dress, background, family structure, beliefs, hairstyles, and more led to a sense of comfort and safety but also boredom and too-frequent agreement.

At my current job, the workforce couldn't be any more diverse. The developers, QA, and project managers come from Sri Lanka, Korea, Japan, China, Russia, India, Arkansas, and and more. I don't interact with hardly anyone who speaks English as a first language. And there's a near equal mix of genders.

When I joined my current company, people wanted me to bring my diversity to introduce new ideas. Initially not wanting to cause friction, I proposed a help solution highly similar to an existing solution (an external instance of Confluence, rather than just an internal one). But the suggestion wasn't received with much enthusiasm, since it seemed too similar to existing lines of thought. People were really hungry to try a new way of doing things. So I said let's do DITA, and given that it actually fit the situation pretty well, people excitedly said yes.

Standardization versus diversity

There's a strong tension between standardization and diversity. While people welcome new ideas, once the new idea becomes a long-time standard, there will come a time when people will feel the burden of uniformity.

As soon as a decision is made to use DITA, it doesn't make sense to continue to embrace alternative authoring methods. If one group wants to use Google Docs, another wants to use Document!X, another wants to use SPFE, another Flare, and another DITA, there will be little hope in integrating our content with each other (except perhaps through some kind of HTML export).

For similar reasons, if PNG is ever to become a competitive player in the global landscape, they can hardly do so speaking 820 different languages. Imagine the variety of tax forms they would need to produce every year. How exactly do you function politically with so many distinct languages? For comparison, imagine if everyone in different states (or even counties) in the U.S. spoke a different language.

Different results from different tools

Diamond makes some other radical assertions. Besides trying out a new model for human living, Diamond wonders whether certain ideas and thoughts come about because of a particular language. Is there something about German that propels people to philosophy? Does the clicking sounds of Australian Bushman lead to a particular kind of thinking that may be unique? He notes that some PNG languages have certain nuances in words (such as 8 different meanings from the same word with different intonations, etc.) that aren't captured elsewhere.

Applying the same idea to help authoring, could some tools and methods yield results that other tools cannot? I certainly think the case could be made for this, much more strongly than the case for human language producing different kinds of thoughts.

For example, using Google Docs encouraged massive amounts of internal collaboration on a scale I'd never seen before. Flare allowed me to style PDFs through CSS. Mediawiki allowed for each group to have autonomy and freedom with their own content pages. DITA provides me with a lot of capability for conditional profiling. SPFE allows for better navigation from web searches. When we encourage tool diversity, we open ourselves up to the possibility of new results and outcomes.

Sameness has some strategic benefits, for sure, but sameness also introduces undesirable stagnancy. Imagine, for a moment, if everyone in tech comm authored in DITA. We would largely be stuck in the same ruts. Help would follow the same pattern, separating concepts from topics in awkward ways. The outputs would look somewhat the same (lots of little topics). The same tool would probably lead to similar approaches for organization (massive TOCs), similar mindsets about how to document features (tasks! tasks! tasks!), and the kind of interactions possible (i.e., next to none). We would see lists and paragraphs and tables and little else in help content.

Add a couple of more factors of sameness -- everyone authoring with the exact same style, arriving and leaving at the same time, wearing the same uniform to work -- and it's hard to see how an innovative thought will ever arrive on the scene. Things might continue in this gray sameness for decades before someone starts thinking differently.

And we need more people to think differently. Help authoring is far from arriving at an ideal solution. DITA falls hopelessly short with API documentation, which is exploding on the web. When you author in DITA, I think you're less likely to experiment with innovative ideas. For example, in the past, using other methods, I incorporated collapsible sections through jQuery, integrated support content with help content and blog content through Drupal, organized content with various faceted filters to provide dynamic organization through Semantic Mediawiki.

Many of the experiments failed; others proved to be successful. But without an environment that encourages experimentation, innovation, risk, and creative thinking, we never see any advancements. As soon as you standardize, although you enable efficiency, you also minimize innovation.

Granted, with DITA you can specialize and build your own transforms and leverage the XML tagged content in different ways, but let's face it, very few of us are XML developers. As I understand it, there are only a small handful of people (mainly a guy named Jarno Elovita) who work on the technology driving the Open Toolkit.

Instead of piggybacking on the innovations that people use for building websites, of which there are many, many creative technologies, DITA seems to require many more developer skills to take it in creative ways. There's a reason why groups such as Write the Docs haven't taken the slightest interest in DITA -- why would they try to leverage a technology not tightly coupled with the innovation of the web?

I'm not saying it's not possible, but with DITA it seems we are mostly reliant on tool vendors to build new possibilities for us. And those possibilities are expensive solutions that cost thousands of dollars, budget approval, and serious agreement to adopt.

Conclusion

In conclusion, when we consider the current tech comm trend toward tool fragmentation, we should avoid thinking in terms of "fragmentation." Fragmentation suggests that we all started at a common ancestral point of similarity and then diverged on our own paths. In reality, as Bill Swallow rightly termed it, we have a strong and healthy degree of tool "diversity," or rather innovation, and it is this diversity and innovation that leads to advancement, to discovery of new and better ways of help authoring. The more diversity with tools, the better.