I came to the practice of procrastination late in life. I was always one of those annoying people who arrived for appointments early, handed in assignments early, went to bed early.

Becoming a full-time working parent drove me to the dark side.

Now I’m routinely late — late for exercise classes, late going to bed, late getting the kids to daycare.

My forgetfulness factor has increased about 26-fold too. I’ve always been a list-maker, but now I have a few sayings that my husband is sick of: If it’s not in my calendar, it’s not getting done. If it’s not on the grocery list, it’s not going to show up in the fridge.

My work equivalent: If it’s not in XPlanner, it’s not getting done.

However, I’ve also discovered that adding tasks to XPlanner is a necessary but not sufficient condition for something getting done. Ever so occasionally, I’ll realize that a task in my slightly overlong list of tasks for the iteration should have been done… yesterday.

In my pre-kid years (which incidentally and unfortunately coincided with the days of larger doc teams), that just didn’t happen. I had sufficient brain space to accommodate what needed to be done.

My colleague Patti and I decided to elevate this practice of procrastination in agile documentation by giving it a name:

DOCRAGINATION.

Fortunately, in my latest slip into docragination, I got away with it: I wasn’t the only reason for another software build.

As I get older, I’m growing more certain that procrastination in general is not always a bad thing. There’s something to be said for waiting, listening, processing — even sleeping on it — instead of rushing in and finishing.

Patti just reminded me of another of my annoying sayings: What doesn’t get documented today won’t have to be revised later.

Our dilemma: How do we remove the barriers to knowledge about Klocwork’s toolset and developer best practices for creating high-quality code?

The answer: Klocwork Developer Network–a new online portal designed for learning, sharing and discussing all things source code analysis. We have had a lot of fun and a few sleepless nights as we assembled industry knowledge, online forums, computer-based training, best practices from industry experts, and lots of reference and learning resources.

A significant portion of the content on the Developer Network is open for public consumption. By registering and logging in, you get additional videos, demos, CBT and more.

We have a lot of fresh content to add to the site in the upcoming weeks and months, and we want to hear from you about what you would like to see. Why not register now at developer.klocwork.com? Then tell other Klocwork users about the portal too.

Visit Klocwork’s Developer Network at developer.klocwork.com.

Already a my.klocwork.com user? Access the Klocwork Developer Network using your existing my.klocwork.com login. (But note that my.klocwork.com remains the place to go for support tickets and for FTP access to the latest software releases.)

After six years of post-secondary education, my first day of the real world had finally come.   As I approached the doors to Klocwork, I realized it was time to put all my years of education to the test.

Straight out of high school, I had little idea of what career path I should take. Four years of university passed and I graduated with a B.A. in English, but still, I didn’t feel prepared. Another two years of college in media-related studies and, ready or not, it was time to make the leap into the working world.

My first day could be described in exactly two words: a blur. Between getting set up at my desk and meetings with my superiors, it was easy to feel overwhelmed. Nevertheless, after I got past the initial nerves of starting a new job, I felt ready for whatever was to come my way.

As it was put in my very first meeting at the company, I would be given “a taste of everything”. A taste was exactly what I had needed to get myself started and get some experience under my belt.

Fast forward almost two months and the experience has been nothing short of a rollercoaster.

One of my most rewarding and yet most challenging experiences since I started here has been a project which consisted of redesigning part of the documentation wiki. One of my colleagues, Patti, has been in process of designing a new landing page, and I had been asked to carry her design over to the wiki. While the task might seem simple, it has been challenging.

When I first glanced at the page, it didn’t think there would be many issues. I’m not afraid to admit that I may have made a poor assumption.

One revision after another, I faced one obstacle after another. Problems ranged from something as simple as getting the correct spacing to more complex issues dealing with specific browsers. The end of the week was near and I felt as if I was getting nowhere.

I let myself walk away from it for the weekend and came in the following week with a refreshed mindset. While it was quickly becoming evident this particular design would not work, there was still light at the end of the tunnel. With some guidance from the documentation team, we quickly got back on track.

Now with the page’s design nearing completion with approval from the key players, it’s something I certainly feel proud of. It’s a prime example of how much I’ve learned in the short time I have been with Klocwork.

While I know work may not always be fun (a few repetitive tasks come to mind), at the end of the day, I think it is projects like this that make it all worthwhile.

In my next post, I’ll share some more of my experiences working with the support, documentation and training teams.

Do internationalization and localization take the fun and flexibility out of documentation?

And here’s the answer: You betcha, sister!

At the risk of starting a brawl in the documentation department, I’m going to respond  to my manager’s post about our new policy to facilitate the translation of our wiki . It’s a policy I refer to unaffectionately as the Stamp-Out-Fun-and-Flexibility policy.

And yeah, I know that internationalization and localization are important to humanity and, um, sales. It’s just that making things more translatable makes documentation less agile and less fun.

1.    Wikis are agile until you’re not allowed to edit them

The great thing about our wiki is that we can update it during development and post release. Customers don’t need to wait until a new version is published. It’s always current.

The policy sucks because: We’ll have to have a “freeze-by” date to get material out of translators. Changing the docs will lead to higher translation costs. So that run-on sentence and that wrong instruction will go unfixed until the next round. The PR fix that has user impacts will go undocumented until the next release.

2.    So long community

All along, we’ve encouraged customers, partners and internal teams to edit our documentation.

The policy sucks because: Now, we’re going to have to say, “No editing. Yeah, yeah, I know we said to go ahead and edit, but really what we meant was don’t edit.” Our “yes, go ahead and edit” was mistranslated.

3.    Google loves fresh meat.

For SEO, churn is great. Search engines love to have fresh material to crawl all over.

The policy sucks because: Less content churn is bad for findability.

4.    A fun, engaging tone makes documentation more readable.

A light tone, particularly in error messages, can defuse frustration.

The policy sucks because: Our writing will have to go back to being dry, dry, dry. No more “Why you’re here”.

What are the predictions on the outcome of this fight? Well, I lift weights occasionally, but Helen fights dirty. It’s anyone’s guess, but I think I’m going to lose this one. That’s okay. I’m used to it.

In a previous post, I discussed the problems we encountered when considering translating our entire MediaWiki-based documentation suite. I talked about how to get content out of the wiki for translation, and then get translated content back to our users.

In this post, I want to discuss translation and globalization requirements more generally, and how our small, agile doc team, working in MediaWiki, handles each requirement. Fulfilling these requirements results in lower translation costs and easier translation:

• Provide a medium for the translated documentation that accommodates text expansion
• Use preformatted styles
• Minimize the amount of text to be translated
• Minimize content churn
• Write in a style that allows easy translation

A medium for the translated documentation

Full marks on this requirement. Delivering the translated documentation in a Japanese sister wiki will work well. We also integrate our documentation with our software as JavaHelp, and there are no issues with text expansion in either medium.

Preformatted styles

Again, no issues here. MediaWiki provides heading and formatting styles that are preserved in the XML export, so no one needs to waste time on formatting the translated text.

Minimizing the amount of text

I didn’t have time to write a short letter, so I wrote a long one instead. – Mark Twain

Here’s where the slope gets slippery. Shorter takes longer. With a small team under constant pressure to keep up with agile development, it’s hard to find the time to write concisely. It’s also hard to find time to deal with legacy content.

Minimizing the amount of documentation makes sense for the English version as well as translations. And it makes for easier maintenance, too.

Minimizing churn

There are two opportunities for content churn: during development, and after the release.

During development. Ideally, we’d provide an initial drop to the translators at Beta, and pledge that we’re something like 80% complete. But in agile development, features are constantly refined as a result of testing and customer feedback. Features are added to the release as resources permit, and as product management becomes aware of new customer requirements. With a small team, we work on documenting features right up to the release date. Our development, test, and product management teams review the docs whenever they have time. And as perfectionists, we just can’t resist editing… and re-editing. An agile wiki is a highly flexible creature. But churn is its middle name.

After the release. We continue to fix problems we find in the English documentation, and our customers can edit too. That’s the whole point. Presto: The translation is out of date.

Easily translatable style

We’ve adopted a casual, conversational, humorous style as an attempt to engage our users. But this type of style can be difficult to translate. It can also be difficult for ESL readers to understand. And even non-North American English speakers might find our humor… unfunny.

Here are just a few things we need to do:

• keep sentences short
• simplify the grammatical structure
• avoid idioms and jargon
• create a more extensive glossary
• avoid text in graphics

So, in our spare time, we’re updating our style guide, and when that’s done, we’ll be creating a review checklist for translation and globalization requirements. Our style guide will be funny, because so far, no one has asked us to translate it.

Good reading

I found the article “Maintaining Documentation Across Several Languages” helpful in my research.

We moved all of our user documentation from Author-it to MediaWiki a few releases ago. At that point, we translated only a part of our documentation to Japanese – the help pages for detected issues. For these wiki pages, we used MediaWiki language templates to display language links at the bottom, and we copied-and-pasted the translated text.

For our most recent release, we expanded the translation effort. This meant more copy-and-paste – from the wiki to Microsoft Word, to send to the translator, and then from Word to the wiki, when we received the translated text.

We discovered that the language templates don’t work when the page title contains a backslash, so we had to change some page titles – for example, some of our page titles include “C/C++”. In MediaWiki, changing a page title means manually editing all pages that link to that page – not so fun.

Recently, one of our product managers (who’s been doing double-duty as localization coordinator – a.k.a. Copy-and-Paster Extraordinaire) said that he needed to get a quote on translating the entire wiki into Japanese. Warning bells went off in my head. I wondered:

• How do we ensure that shared content is translated only once?
• How do we get the material out of the wiki to send to the translator for a quote and translation?
• Where do we put the translated text?
• How well does our documentation lend itself to translation?

Handling shared content

We use MediaWiki templates to “single-source” documentation. Much as in traditional documentation platforms, wikis allow you to reuse content. For instance, we use a template for the current release number, so that we have to edit it only once per release. We also use templates for information that’s identical across multiple Klocwork tools – from phrases to multiple paragraphs.

Getting the content out of the wiki – attempt #1

Clearly, copy-and-paste for 435 wiki pages plus templates = carpal tunnel syndrome.

Given that we were in the last days of our release, my brain was perhaps not at its most efficient. We use the MediaWiki Book extension, so that we (and our users) can create collections of pages that can be downloaded as PDF. To get a translation quote, I decided to create a massive PDF.

This was no easy task. I don’t recommend it, so I won’t explain the torture involved. Plus, the resultant PDF did not handle the shared text, so the word count was not accurate.

Getting the content out of the wiki – attempt #2

Eventually, once our release was out the door and my head cleared, I did some more reading and investigated MediaWiki’s XML export feature.

First, I used the MediaWiki special page “All Pages” to display a list of all of the pages in the Main namespace. This list is displayed in three columns over several screens, so I pasted all of the page names into an Excel spreadsheet. Then I created a single column of page titles. Next, I copied this list from Excel into the MediaWiki page Special:Export. This page requires only a straight list of page titles, one per line, without the surrounding double square brackets, so the copy-and-paste from Excel worked perfectly. I chose to include only the current revision, not the full history. I chose to include templates (shared text). And I chose to save to file.

To my great relief, the XML file was very readable, and shared text was included only once. The translator provided a second quote and said that they felt more confident with the XML file than with the earlier PDF.

So, we’d taken care of points 1 and 2: We got the material out of the wiki for a quote and translation, and ensured that shared content would be translated only once.

A medium for translated content

Now, what to do with the translated text? The only sane option would be to use MediaWiki’s XML import feature. To do this, we’d need to abandon our current model of having the Japanese pages alongside the English in the same wiki. Instead, we’d need a separate Japanese wiki, where we could simply import the translated XML file. Changing our translation model also means changing how the Japanese documentation is integrated into our software.

Documentation style

Last and most painful: how well does our documentation lend itself to translation? My research and common sense told me that we have some work to do. For example, to make our documentation more engaging and user-friendly, we’ve adopted a casual, conversational, and (some might say) humorous style. This can make translation tricky, but it can also be problematic for ESL readers. And what we think is funny here in Canada may make no sense, or may be just plain annoying, across the pond. I’ll write more about style issues and translation in a future post.

In the beginning was the word. And thanks to Guttenberg, the word was often enclosed in a glossy book and sold for $49.95 at my local computer store. The noble computer book with a shelf-life of six months was the perfect solution for a piano with a missing wheel. Computer books (part of the discipline of book-learnin’) are an increasingly endangered species. Sales of computer books have been off by 8 to 10% year over year for a decade, a trend that shows no sign of slowing.

Still, I miss old-school, printed computer books. It wasn’t so much what they contained, as what they quantified. Using the Rumsfeld model, a nice fat computer book helps me quantify the unknown unknowns. As I tackle a new body of knowledge – say a new language or IDE – the unknown unknowns are infinite. As soon as I have that book in my hand, the unknown unknowns turn into known unknowns. I now know how much I don’t know, and the table of contents is my new best friend – whether I read the book or not. It is hard to beat stretching out at the cottage with a refreshing beverage and the latest tome on source code analysis.

But software developers don’t typically think in linear ways. While many of us are college or university trained, in spite of years of classroom training we run away from learning new knowledge in the old school way. Developers search for the answer to their current problem, rather than accumulating knowledge for its own sake. They listen and watch communities, RSS feeds and blogs for trends. They look for on-line videos, podcasts, newsletters, and magazines. They may even find a book in PDF, and print out a few pages that they want to use for reference.

The challenge for technology companies is to make our collection of facts, tools and interfaces accessible without binding it all up in a single document with a cover. Wikis, on-line API tutorials, developer communities, and a host of other information bits need to replace the old book model.

Of course, it’s hard to argue with Groucho Marx, when he said “Outside of a dog, a book is man’s best friend. Inside of a dog it’s too dark to read.”

Documentation is the castor oil of programming. The managers know it must be good, because programmers hate it so much. Gerald M. Weinberg

I used to be a strong believer in formal doc reviews. Distribute a draft, plan a meeting, and have everyone gather around the table. But in the last few years, my team has moved towards mostly meetingless reviews–because people hate review meetings (you know, like code reviews, only worse), because people haven’t always read the drafts when they get to the meeting, and because some of our dev team is overseas.

• First, we distributed PDFs and asked reviewers to submit comments in email or on a hard copy. For the overseas team, email was the only option. This is not fun for either the reviewer, who has to do a lot of copying and pasting and referring to page numbers, or for the writer.
• Then we tried Adobe Acrobat PDF reviews, which allowed all reviewers to comment on the same PDF and view others’ comments. This was a big improvement over the email method.
• Now that all of our product documentation is hosted on a MediaWiki-based site, we’ve asked reviewers to edit the pages themselves, or add comments to the Talk pages. This makes life much easier for both reviewers and writers.

Still, as Anne Gentle stresses in Conversation and Community, using a collaborative medium doesn’t guarantee that collaboration will happen.

How do we encourage developers and testers to “own” the documentation for their tools, and to think of help as part of the product? If we can get developers and testers to RTFM, the benefits are obvious. They understand the tools in a way that no one else does, so they’ll provide feedback that no one else can. And they’ll become familiar with the help for the tools they’re responsible for, so they’d know whether a change they’re making or testing would affect the help.

I thought up a few ways that might increase the amount of review feedback:

• Create review tasks in our Agile project tracking tool, XPlanner. A top-down approach, and I wasn’t enthusiastic about it. Kinda like the daily castor oil treatment.
• Make everyone’s MediaWiki user page into their doc review page; we’d add links to these pages and reviewers would be notified through email, then they could delete the link when they’ve reviewed it. A nice bottom-up approach, I thought, in the spirit of the wiki.

But encouraging collaboration may be less about tools and more about process. If we involve reviewers earlier, they can tell us what they think before we’ve written a draft. A draft takes a long time to review, and if a reviewer doesn’t like it, they might not provide any feedback at all.

As Donna L. Davis says in a review of Andreas Rüping’s Agile Documentation:

Documentation isn’t bad. But bad documentation is terrible.

Is reviewing docs worse than eating Brussels sprouts? Do you review docs when asked, or do you hide the invitations under the edge of your plate, hoping mom won’t notice? Is the help so bad that you can’t be bothered? Are you just too busy? Are you one of those people who never consults the help for tools you use? Do you think your users will be able to use the tools you’re developing or testing without the docs?

What would make you more inclined to “own” the help for the tools you’re developing or testing?

When I was documenting a new refactoring plugin for Vim, I checked out the Vim web site, and came across this blasphemy:

Vim isn’t an editor designed to hold its users’ hands. It is a tool, the use of which must be learned.

Later, someone sent me this beauty, from Elitist Jerks:

Stop being lazy and read.

Are users lazy? Do they expect hand-holding? Do they expect one button and no manual?

Or is this more true to life?

In the end, it probably comes down to this: Make tools usable. Then technical communicators can spend more time creating truly helpful help, and less time explaining a bad UI.

If our goal as communicators is not just great help, but a great product, Agile makes more sense than ever.  If we want our usability suggestions to be implemented, we need to get developers’ attention while they’re working on that feature. Find the rough edges that would require a lot of splainy-splainy, request a change, and then rejoice that we don’t need to explain what’s now obvious. Sometimes it’s hard for me to decide what’s a rough edge. Would my audience of developers find this as confusing as I do? But I’m learning to trust my gut.

At the same time, though I appreciate the benefits of Agile, I’ve started to worry less about the help being “done” at the end of an iteration; instead, I want to make sure I understand a feature well enough before the end of the iteration to suggest design changes and know what help will be required.

At the risk of sounding like a co-dependent, in this post I discuss coping mechanisms that a “big picture” technical  writer (say, like my friend Beulah) can use to adjust to working in the granular conditions of an agile environment.

Don’t give up the big picture

Wouldn't it be great to use XPlanner for everything? Just imagine the velocity I could achieve.

When you work on a bunch of stories or tasks, it’s trees, trees, trees everywhere  you look and not a forest to be found.  This means that a nice concise how-to could be a long way off while you document myriad  features.

My advice is to finish the pieces and try to get to the minimalist documentation afterwards. In fact, Shannon Greywalker suggests going back and fixing things up later, but mentions that the business case for this can be a bit weak.  I think it’s worth the effort if you can swing it.

I’ve blogged before about how workflow can be helpful in getting the big picture. If the feature is big enough, workflow is your friend and can really pull you through.

Go for “What’s New” first
For each release, we document the cool new features on a “What’s New” page and “What’s New” is where I like to start.

If you can neither summarize nor explain why people would want to use a new feature, you have no business documenting it. “What’s New” keeps me focused on the whole point of the development work in the first place.

“XPlan” everything
I was a slow adopter of XPlanner, which is the tool our team uses to document development, testing and now, documentation.

Documentation has a separate project in XPlanner where we track our stories. At first, I found it difficult to update XPlanner regularly because some of our work can be difficult to account for.

For example, one our sales engineers is a prodigious reader of documentation who meanders over for his (thrice) daily “found a spelling mistake” or “did we document?” or “why can’t titles be printed on the PDFs generated by the wiki?” questions. All good points, with some requiring immediate action and others requiring medium and long-term planning.

But after reading Getting Things Done, I can really see XPlanner as a great life planning tool. See the screenshot above. For low self-esteem days, I recommend first completing tasks such as “Wake up”, “Shower” and “Eat breakfast” under the Personal Maintenance story.

Targeted procrastination
We’ve gone from blanket procrastination, which was a two-week offset, to carefully picking features that could benefit from a little more “fleshing out” before documentation. I like this approach because we show great planning with our procrastination.

For example, I like to spend bigger chunks of time on one thing, so I may delay documenting a bigger feature in favor of knocking some smaller stuff off the list one week, so I can string together several days in a row for the big stuff. I work better that way.

Ask a lot of questions
My modus operandi is asking as many questions as possible. Be annoying, but in a friendly and charming way. There’s an art to asking good questions, but sometimes it takes a bunch of stupid ones to get there. Dive in.