Agile Tenet #10 – Simplicity is Essential

Tenth in a series of posts examining the Twelve Principles of Agile Software and how each of these tenets can (or can’t) be applied or adapted to technical writing.

*****

Simplicity–the art of maximizing the amount of work not done–is essential.

When I was a child I read Cheaper by the Dozen by Frank and Ernestine Gilbreth. Their parents were the pioneering industrial engineers and motion study experts Frank Bunker Gilbreth and Lillian Moller Gilbreth. I still remember one of the opening descriptions of their father:

…at home or on the job, Dad was always the efficiency expert. He buttoned his vest from the bottom up, instead of from the top down, because the bottom-to-top process took him only three seconds, while the top-to-bottom too seven. He even used two shaving brushes to lather his face, because he found that by doing so he could cut seventeen seconds off his shaving time. For a while he tried shaving with two razors, but he finally gave that up.

“I can save forty-four seconds,” he grumbled, “but I wasted two minutes this morning putting this bandage on my throat.”

It wasn’t the slashed throat that really bothered him. It was the two minutes.

I re-read the book several times as a child. Probably because my father was an engineer, and I could see Mr. Gilbreth as a slightly more charming version of my father. And I have to say that those repeated readings had an effect on me, instilling me with a bit of a secret desire to be an efficiency expert. When I think about “maximizing the amount of work not done” I always think of Mr. Gilbreth.

This tenet focuses on one of the cornerstones of efficiency – the KISS principle: Keep it Simple, Stupid. This is such a key concept, and yet, so often people forget it. Don’t make extra work for yourself. Find the simplest solution possible to problems. Work smarter, not harder.

Some of the ways that I like to keep things simple include:

• Using styles and templates. Over the years, I’ve always been surprised at the number of people (including the occasional technical writer) that don’t use styles to format their documents, especially Word documents. The first thing I do when I start working with an authoring tool or a document is inspect the template. Knowing what styles are available saves time when it comes to thinking about how I want to arrange the information that I’m writing. When I’m the one creating the templates (which I’ve done in both FrameMaker and Flare) I first create a basic set of styles, then add to them as needed. When I’m dealing with an overly complex FrameMaker template, I’ll delete the styles that I don’t need. I can always import them back into the document if the need arises.
• Writing short, simple modular content that is chunked into concept, task, and reference topics. Chunking content into smaller pieces makes it easier to add, remove, and rearrange content as needed. It also reduces the amount of content that users need to scan to find information within a topic.
• I try to avoid overly complex branching procedures because I find them confusing. I assume that my users would find them confusing too. I try to write short, simple procedures. If a procedure becomes long and involved, try to break it into smaller procedures.
• Don’t reinvent the wheel. Especially when it comes to something like Style Guides. Pick one of the major style guides (Apple, Chicago, Microsoft, Sun, Xerox) and only document where you differ from it. As a lone writer I don’t have time to write my own in-house style guide. I use the Microsoft Manual of Style (partly because Microsoft is so ubiquitous that it feels familiar to most people, and partly because I can always find a copy on the shelf at my local Barnes and Nobles).
• Probably the most important way to maximize the amount of work not done is not to include information that the customer doesn’t really need in your documentation. Always keep the customer and their tasks in mind. Sometimes that means that you have to trust your own judgment over that of your developers as to what the user needs to know. Yes, the developer thinks that customers need to know the algorithms and all the other little details about how the software does its thing. But chances are, your customers really don’t need or want that level of detail about how things work. They assume that when they click the button, it will do what it’s supposed to do. You don’t need to be a mechanic to drive a car, and most users don’t need to know the inner workings of software to be able to use it.

Simplicity is essential. Work smarter, not harder.