“The biggest problem with Word is that it is way too much program for 90% of creative writers and self-publishers.” JW Manus.
Yep. I read discussions of Word on the network all the time. Many of the comments are negative. Sometimes I take time to defend Word or offer tips on how to use Word more effectively. But I have to admit that something about Word is seriously broken, but not the application itself. It’s better than ever.
Agile programing and continuous update have changed the software industry. In the old days, we spent months or years designing a program down to the last detail. Then code and unit test for another year or so. Then quality assurance system testing executed tests based on the design, not the as-built code. Every failed test was a dagger in your heart. If you were “lucky” QA was cut short to meet roll out deadlines. And, more often than not, when the product finally hit the customers, it was a travesty.
Software is maddeningly complex, and its presence often changes its environment in ways that invalidate the requirements which the software is intended to meet, and software is more fluid than any physical object. A program designed several years before a real user touches it, never meets user expectations.
The enormous cost overruns and failed projects that plagued software of the 1990s were largely due to a methodology called called “waterfall development.” In the waterfall, design, construction, testing, and acceptance of the final product proceed in strict order. Each phase must be completed and signed off on before the next phase can begin. Administrators loved it because they always had signed documents to shake in people’s faces. It worked great for bridges, skyscrapers, World War II, and the moon landing, but failed for software.
Today, the prevailing approach is to build software in small increments. Build a single feature, release to a test user group, look at the problems and let the release generate further ideas, then fix the defects, incorporate the ideas, and roll out another incremental release. Keep the increments small and rinse and repeat forever. The network bandwidth and speed available today makes it possible to develop continuously in small increments. This has proven to be much more successful than the waterfall.
Microsoft and many other software developers have adopted the agile methodology, but the new methodology has its own problems.
An unforeseen consequence of agile programming and continuous update is that documentation doesn’t keep up well with the development of the product. Microsoft has opened a fire hose of development and innovation in Word and documentation has not kept up.
Writing and revising documentation often takes as much time as developing and testing code. Asking a writer to document incomplete code easily degenerates into a time-wasting mess. Distinguishing defects from features is often hard and software can turn on a dime. The documentation often has to be rewritten at the last minute anyway. Consequently, the documentation usually trails behind the product.
However, documentation is also critical to software quality. If a feature is not clearly enough documented for a customer to use it well, the system is broken, no matter how perfectly it works.
Microsoft Word has suffered from the efficiency of agile development and frequent updates. Word processing in general has leaped ahead in the last few decades and it becomes more powerful with every automatic software upgrade, faster processor, increase in available memory and storage, and jump in network bandwidth.
So often, when I read of writer’s problems with Word, I think of some poor sap trying to cut a two-by-four with a Skillsaw without plugging it in or turning it on.
And I sympathize. They’re writers. They don’t have time or inclination to become experts on a huge and challenging system like Microsoft Word. Writers usually learn just enough to get the job at hand done and then get back to their serious business of writing. The solution might work but be all wrong down the road. Two months later, when they tackle a similar problem, their half-learned and half-remembered solution lets them down. And intervening updates may have improved the process, but they also changed it. Who wouldn’t be mad?
Microsoft has not made it easy. These days, most developers aspire to programs that are so simple to use, they don’t need documentation. But that’s an aspiration that is devilishly difficult to realize when the work done by the program is as complicated and hard to understand as word processing today.
I’m a software engineer and architect who coded his first word processor at the same time he started using word processors forty years ago. In recent years, I’ve burned hours puzzling over Word help forums. I’ve resorted to reading the xml in docxs and studying Word OLE documentation to get a feeling for Word’s internals. I used to know developers on the Word dev team and watched them stumble while using Word. In the end, I’ve always concluded that Word is a good product, well-designed with surprising power and flexibility, but first priority for writers is to write, not become Word experts.
Nevertheless, the writers who plug in their Skillsaw, instead of going back to a handsaw, will make more sawdust.
Today, if you are having trouble with Word, I suggest getting a copy of Word For the Wise by JW Manus. It will help. I have some disagreements with some of her approaches—I go farther with styles and I think my process is easier and more foolproof—but you won’t go wrong following her advice. Her book is still the best I’ve seen.
