Whispers from the Myth Teller

A couple of years ago, I was speaking with a fellow techwriter who had attended a conference on software design. She attended a lecture by an American software company that had embraced a radical development process.

Most IT companies follow the waterfall development process which basically means you start with a set of requirements, come up with a basic design (which is usually quite vague because it is rushed), write the code for that design, test the code, fix the bugs, and release it.

Somewhere in that process (between the writing of code and fixing of the bugs), the documentation process starts. Because the writer comes online in the middle of the process, the writer is always playing catch-up. He'll write sections of the User Guide, the code will change due to bug fixes, which in turn affects the documentation in terms of procedures and/or screen grabs. MOST sections of a User Guide will be rewritten, rewritten, and rewritten.

All the while, the release date looms in the distance and everyone scrambles to get their stuff ready so that the application will release on time. Usually, this date is selected in terms of its proximity to financial quarters or trade shows, rather than being selected in terms of when the application is ready.

So this American software company reported that, when they tried to follow the waterfall process, they would regularly blow their release dates, break the budget, and work their people excessively. Something had to change, so they flipped the process on its head.

The Product Designers went to the Documentation team and had them write the User Guide for the product BEFORE the code was written. This User Guide would become the extremely detailed specification that the programmers would then follow to write the code. You want to know how the program is supposed to work? RTFM.

When the company followed this plan, they stayed on budget and released a stable product on time. To be sure, it lengthens the planning stage, but at least the programmers have a very well-defined document on how the products works to reference.

Even with this plan, the Doc team is still busy once the coding starts. Bugs come in and some procedures/screen grabs will change, but these changes need to be justified and the writer is much more involved in the development process. No more cowboy coding, which ultimately leads to broken code, inaccurate documents, and extending testing times.

Speaking from the writer's point of you, I can tell you that I like the thought of being DRUNK WITH POWER (*cough*), but this process does produce solid results. And it also elevates the role of the technical writer in the development process, which I can tell you is currently somewhere between the last rung on the priority ladder and oblivion.

The ironic thing in the IT business is, with all the obsession with new technologies and new ideas, the thing that scares IT culture the most is change at the development level.

Tonight is the Winter Solstice, the longest night of the year. Many people I know will be lighting candles and holding all night vigils to welcome the return of the sun after being away for so long. That might sound a bit weird, but how many of you have a dead pine tree in your home covered in lights and shiny tinsel. When you take a step back, Xmas has some weird traditions around it.

Looking back, it's been a transformative year. I've been going through my own metamorphosis in terms of my career path (moving from technical writing to biography writing), but there are a few others I know who are struggling with their own demons right now. All of life's challenges seem to be building to a surging point and these people are trying to decide if they can ride the avalanche or be swept away by it.

For my part, technical writing is a lucrative career path but it's starting to get soul-crunching. I'm hoping the biographies will be just as lucrative, but also more satisfying. It's difficult to get excited about your work when you write technical manuals that, by their very nature, have a reputation of being unhelpful and uninteresting. Of course, MY technical manuals are helpful and well-designed, but I work in an industry that does not value good documentation.

However, the biography is something that people can value, not only when they first get it, but also over time. I feel good about the product and I think it's something that can really respond to a need for people searching for personal history and family roots. But I still need to pay the bills, so I worry about the realities of money and providing for my family.

I strongly believe in this project, but the future is fraught with peril. What makes it easier is having a strong support from friends and family; if they believe in me and my project, I can't be too far off-base, can I? Maybe I need to put some trust in them too...

So to those people who are struggling with their own perils, I can only advise them to lean on their friends and family (both biological and selected). We're dying to help you, if you'll let us.

So let's raise a glass to each other, count our blessings, and carry each other into a new year. It's going to rock.

Nicked this one from LightSpeed: Revenge of the Sith from a Japanese perspective.

Georgie Lucas could learn a thing or two here. Maybe the bad translation is a sign of a weak script? Either way, the translation brought more pleasure to me than the original script.

Now if you'll excuse me, I must give first aid to my disheveled hair projection before I get made by the Presbyterian Church.