Documentation is the work that is often neglected by developers and sometimes by managers. This is often due to a lack of time towards the end of development cycles, and the fact that people think they are bad at writing. Some of them are bad indeed, but the majority of them are able to produce a fine documentation.
In any case, the result is a disorganized documentation made of documents that are written in a rush. Developers hate doing this kind of work most of the time. Things get even worse when the existing documents need to be updated. Many projects out there are just providing poor, out-of-date documentation because the manager does not know how to deal with it.
But setting up a documentation process at the beginning of the project and treating documents as if they were modules of code makes documenting easier. Writing can even be fun when a few rules are followed.
This chapter provides a few tips to start documenting your project through:
- The seven rules of technical writing that summarize the best practices
- A reStructuredText primer, which is a plain text markup syntax used in most of the Python projects
- A guide for building good project documentation
Writing good documentation is easier in many aspects than writing code. Most developers think it is very hard, but by following a simple set of rules it becomes really easy.
We are not talking here about writing a book of poems but a comprehensive piece of text that can be used to understand a design, an API, or anything that makes up the codebase.
Every developer is able to produce such material, and this section provides seven rules that can be applied in all cases:
- Write in two steps: Focus on ideas and then on reviewing and shaping your text.
- Target the readership: Who is going to read it?
- Use a simple style: Keep it straight and simple. Use good grammar.
- Limit the scope of the information: Introduce one concept at a time.
- Use realistic code examples: "Foos" and "bars" should be avoided.
- Use a light but sufficient approach: You are not writing a book!
- Use templates: Help the readers to get habits.
These rules are mostly inspired and adapted from Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects, Wiley, a book by Andreas Rüping that focuses on producing the best documentation in software projects.
Peter Elbow, in Writing With Power: Techniques for Mastering the Writing Process, Oxford University Press, explains that it is almost impossible for any human being to produce a perfect text in one shot. The problem is that many developers write documentation and try to directly come up with some perfect text. The only way they succeed in this exercise is by stopping writing after every two sentences to read them back and doing some corrections. This means that they are focusing both on the content and the style of the text.
This is too hard for the brain and the result is often not as good as it could be. A lot of time and energy is spent in polishing the style and shape of the text before its meaning is completely thought through.
Another approach is to drop the style and organization of the text and focus on its content. All ideas are laid down on paper, no matter how they are written. The developer starts to write a continuous stream and does not pause when he or she makes grammatical mistakes, or for anything that is not about the content. For instance, it does not matter if the sentences are barely understandable as long as the ideas are written down. He or she just writes down what he wants to say with a rough organization.
By doing this, the developer focuses on what he or she wants to say and will probably get more content out of his or her mind than he or she initially thought they would.
Another side-effect when doing free writing is that other ideas that are not directly related to the topic will easily go through the mind. A good practice is to write them down on a second piece of paper or screen when they appear, so they are not lost, and then get back to the main writing.
The second step consists of reading back the whole text and polishing it so that it is comprehensible to everyone. Polishing a text means enhancing its style, correcting its faults, reorganizing it a bit, and removing any redundant information it has.
When the time dedicated to writing documentation is limited, a good practice is to split this time into two halves—one for writing the content and one to clean and organize the text.
When writing content, there is a simple question the writer should consider: Who is going to read it?
This is not always obvious, as a technical text explains how a piece of software works and is often written for every person who might get and use the code. The reader can be a researcher who is looking for an appropriate technical solution to a problem or a developer who needs to implement a feature with it. A designer might also read it to know if the package fits his or her needs from an architectural point of view.
Good documentation should follow a simple rule—each text should have only one kind of reader.
This philosophy makes the writing easier. The writer precisely knows what kind of reader he or she is dealing with. He or she can provide concise and precise documentation that is not vaguely intended for all kinds of readers.
A good practice is to provide a small introductory text that explains in one sentence what the documentation is about and guides the reader to the appropriate part:
Atomisator is a product that fetches RSS feeds and saves them in a database, with a filtering process. If you are a developer, you might want to look at the API description (api.txt) If you are a manager, you can read the features list and the FAQ (features.txt) If you are a designer, you can read the architecture and infrastructure notes (arch.txt)
By taking care of directing your readers in this way, you will probably produce better documentation.
Seth Godin is one of the best-selling writers on marketing topics. You might want to read Unleashing the Ideavirus, Hachette Books, which is available for free on the Internet (http://www.sethgodin.com/ideavirus/downloads/IdeavirusReadandShare.pdf).
Some time ago, he made an analysis on his blog to try to understand why his books sold so well. He made a list of all the best sellers in the marketing area and compared the average number of words per sentences in each one of them.
He realized that his books had the lowest number of words per sentence (thirteen words). This simple fact, Seth explained, proved that readers prefer short and simple sentences, rather than long and stylish ones.
By keeping sentences short and simple, your writings will consume less brain power for their content to be extracted, processed, and then understood. Writing technical documentation aims to provide a software guide to readers. It is not a fiction story and should be closer to your microwave notice than to the latest Stephen King novel.
A few tips to keep in mind are:
- Use simple sentences. They should not be longer than two lines.
- Each paragraph should be composed of three or four sentences, at the most, that express one main idea. Let your text breathe.
- Don't repeat yourself too much. Avoid journalistic styles where ideas are repeated again and again to make sure they are understood.
- Don't use several tenses. The present tense is enough most of the time.
- Do not make jokes in the text if you are not a really fine writer. Being funny in a technical text is really hard, and few writers master it. If you really want to distill some humor, keep it in code examples and you will be fine.
There's a simple sign of bad documentation in a software—you are looking for some information that you know is present somewhere but you cannot find it. After spending some time reading the table of contents, you are starting to grep the files trying several word combinations but cannot get what you are looking for.
This happens when writers are not organizing their texts in topics. They might provide tons of information, but it is just gathered in a monolithic or non-logical way. For instance, if a reader is looking for a big picture of your application, he or she should not have to read the API documentation—that is a low-level matter.
To avoid this effect, paragraphs should be gathered under a meaningful title for a given section, and the global document title should synthesize the content in a short phrase.
A table of contents could be made of all the section's titles.
A simple practice to compose your titles is to ask yourself, "What phrase would I type in Google to find this section?"
Foo and bar are bad citizens. When a reader tries to understand how a piece of code works with a usage example, having an unrealistic example will make it harder to understand.
Why not use a real-world example? A common practice is to make sure that each code example can be cut and pasted in a real program.
To show an example of bad usage, let's assume we want to show how to use the parse() function:
>>> from atomisator.parser import parse >>> # Let's use it: >>> stuff = parse('some-feed.xml') >>> next(stuff) {'title': 'foo', 'content': 'blabla'}
A better example would be when the parser knows how to return a feed content with the parse function, available as a top-level function:
>>> from atomisator.parser import parse >>> # Let's use it: >>> my_feed = parse('http://tarekziade.wordpress.com/feed') >>> next(my_feed) {'title': 'eight tips to start with python', 'content': 'The first tip is..., ...'}
This slight difference might sound overkill, but in fact it makes your documentation a lot more useful. A reader can copy those lines into a shell, understand that parse uses a URL as a parameter, and that it returns an iterator that contains blog entries.
Of course, giving a realistic example is not always possible or viable. This is especially true to very generic code. Even this book has few occurrences of vague foo and bar strings where the name context is unimportant. Anyway, you should always strive to reduce the amount of such unrealistic examples to minimum.
In most agile methodologies, documentation is not the first citizen. Making software that works is the most important thing over detailed documentation. So a good practice, as Scott Ambler explains in his book Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, John Wiley & Sons, is to define the real documentation needs, rather than create an exhaustive set of documents.
For instance, let's see an example documentation of some simple project—ianitor—that is available on GitHub under https://github.com/ClearcodeHQ/ianitor. It is a tool that helps registering processes in the Consul service discovery cluster, so it is mostly aimed at system administrators. If you take a look at its documentation, you will realize that this is just a single document (the README.md file). It only explains how it works and how to use it. From the administrator's perspective, this is sufficient. They only need to know how to configure and run the tool and there is no other group of people expected to use ianitor. This document limits its scope by answering one question, "How do I use ianitor on my server?"
Every page on Wikipedia is similar. There are boxes on the one side that are used to summarize dates or facts. At the beginning of the document is a table of contents with links that refer to anchors in the same text. There is always a reference section at the end.
Users get used to it. For instance, they know they can have a quick look at the table of contents, and if they do not find the info they are looking for, they will go directly to the reference section to see if they can find another website on the topic. This works for any page on Wikipedia. You learn the Wikipedia way to be more efficient.
So, using templates forces a common pattern for documents and therefore makes people more efficient in using them. They get used to the structure and know how to read it quickly.
Providing a template for each kind of document also provides a quick start for writers.