In early December, researchers at DeepMind, the artificial-intelligence company owned by Google’s parent corporation, Alphabet Inc., filed a dispatch from the frontiers of chess.
A year earlier, on Dec. 5, 2017, the team had stunned the chess world with its announcement of AlphaZero, a machine-learning algorithm that had mastered not only chess but shogi, or Japanese chess, and Go. The algorithm started with no knowledge of the games beyond their basic rules. It then played against itself millions of times and learned from its mistakes. In a matter of hours, the algorithm became the best player, human or computer, the world has ever seen.
“One Giant Step for a Chess-Playing Machine”, Steven Strogatz, New York Times, Dec. 26, 2018
After a week of reading and writing complex technical documentation for sysadmins of virtualization software, the article above got me wondering about the effects of AI on my profession.
Presently, experts with years, if not decades, of experience and knowledge are responsible for configuring and running these systems. By definition, their expertise is partially outdated — new features, patches, and errata come out all the time.
As AI takes on greater responsibility for setting up and managing these systems, the knowledge threshold for an end-user to run those systems decreases. This dynamic is a well-established pattern of technology decreasing barriers to entry. The same person with the same amount of learning becomes capable of more significant results. For example, in the past, a ship’s navigator required extensive mathematical and navigational training plus years of experience to produce reliable results. Today, an untrained person with limited experience and an inexpensive GPS unit can achieve outstanding results.
Expertise shifts further up the spectrum. The sysadmin will no longer have to deal with nitty-gritty details, like knowing that one has to “run configuration utility X before deploying Y, to avoid ending up with thousands of connections to orphaned partitions eating up your computing resources.”
As systems become more sophisticated, they impose a more significant knowledge burden, until that burden becomes too costly. The competitive advantage goes to organizations and technologies that remove this burden.
As we develop AI that can learn, handle problems and exceptions, take immediate action, and optimize results, we transition away from writing software documentation that users must read and apply correctly. More expertise will be embedded directly in the software.
Technical writers/communicators operate at the information boundaries between new capabilities and the integration of those capabilities into a smooth, software-assisted, user experience. Software only needs documentation to explain functionality that hasn’t become easy to understand and use.
To express this in terms of the four core Agile principles:
Principle 1: Individuals and interactions over processes and tools
Technical communicators must work as members of each team developing and delivering new products and capabilities. Writers must become “Agile-proficient” and assist groups with Agile processes.
Principle 2: Working Software over comprehensive documentation
Although “documentation” in this principle is referring to project documentation (such as detailed specifications), Agile projects rely on User Stories as a vehicle for talking about requirements and expressing desired functionality. Because talking is ephemeral and synchronous, teams need to capture the essence of these conversations in writing. Writers must become experts in understanding and communicating user stories. These stories must include interactions with both the software and all of the technical information/resources that accompany the software.
Principle 3: Customer Collaboration over contract negotiation
Level 1: (Where “customer” = client/end-user) Iterating the software and the technical information while it is is being delivered to the end customers/users. You must collaborate with customers to understand their information needs.
Level 2: (Where “customer” = software development team) This is why you, as a technical communicator, must work as an embedded member of the software/product/feature development team.
Principle 4: Responding to Change over following a plan
Because Agile development is inherently fluid and dynamic, you have to contribute information on short rapid cycles (hourly/daily?). The technical information embedded in the product IS part of the product. There is no such thing as starting documentation when a feature/capability is nearly complete.
Postscript: Wow! This post is a lot longer than I expected. I’ve been reading and thinking widely on these topics. I hope this is interesting and useful to you.
Originally published at rolfedh.com on December 31, 2018.