Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Responses to Review Post were enormous The number of comments on my recent post, Review of Andrew Etter’s ebook on Modern Technical Writing showed an overwhelming interest in this topic. The post went viral. In addition to 300+ clicks on Twitter and Linkedin, there were about 1,200 page views and an equal number of clicks on the audio files. People spent an average of 5 minutes 11 seconds reading the post. The post had a lively discussion both on techwr-l and in the post’s comments. I want to respond generally to at least one trend in the comments – the idea that the docs-as-code solution won’t scale. By the way, it’s not as if the techniques Etter describes in Modern Technical Writing (or rather the “docs as code” approach) are new. Lots of people (myself included) have been emphasizing static site generators, version control, lightweight markup languages, and other approaches for documentation for a long time. But Etter’s ebook seems to legitimize the approach, and his title “Modern Technical Writing” might have irked a few people who suddenly felt that their XML/CCMS-based approaches were being labeled antiquated. In their responses, a few people argued that that the docs-as-code approach would only work for small shops. For larger documentation scenarios, it wouldn’t scale. For example, one reader said: Having worked in ginormous and more boutique-sized content projects, the tips and methods described in Andrew’s book are geared more towards the boutique-sized end of the spectrum. Which is fine, as there are many writers who work on projects of that size. Another person (who noted that he works for easyDITA) said: I’m sure it could work for a very small team but when you get into tens of thousands of topics (not uncommon) it would be a nightmare. And the entire publishing process enabled by a CCMS offers the advantage of eliminating constant formatting while enabling real time updates. Having multiple Jekyll sites, for example, means keeping track of what is where and somehow making them easily accessible to end users. And what about search? How do you search across all these apps with one search? Etc.,etc. He continued with some more commentary about content re-use and formatting later: let’s imagine a part number changes that is used across multiple products and appears in multiple docs published to various media. How do you change every instance of that part number other than manually looking for them? There are so many reasons why structure was developed. The average tech writer spends as much as 40% of their time formatting their documentation for multiple delivery options. Formatting is automated in XML-based systems. Another person also pointed out the difficulty of scaling these solutions, saying: when content grows, from my experience, it’s really hard to manage it all with a self-made solution. Especially when it comes to translation! These commenters make some good points, so let’s take a look at them in more detail. The points might be summarized as follows: For a project consisting of tens of thousands of topics, the solution would be a nightmare. You can’t identify and change a component that appears in multiple places. Translation becomes problematic. When you have multiple delivery options, this approach becomes inefficient. For a project consisting of tens of thousands of topics, the solution would be a nightmare Let’s look at the first objection: For a project consisting of tens of thousands of topics, the solution would be a nightmare. I’m not entirely sure why a large docs-as-code project would be a nightmare. Microsoft and Rackspace are two examples of large documentation sites that follow a docs-as-code model. SendGrid, Balsamiq, and MongoDB are also more than just “boutique-sized” doc sites. But are massive projects really an issue? How common are projects that h