TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Windows version number references in docs From:"Chuck Martin" <cm -at- writeforyou -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 21 Oct 2003 10:18:10 -0700
"Dana Worley" <dana -at- campbellsci -dot- com> wrote in message news:216986 -at- techwr-l -dot- -dot- -dot-
>
> Those who are driven to make disparaging comments about the
> quality of Microsoft products (or other vendor's products), must not
> work in the software industry or at least must not work closely with
> their engineering teams.
I'd say just the opposite is true. Many who work in the software industry
know software well and work closely with people whose primary job is
programming, and for those of us who work (of have worked) at places where
it is done well, we *know* it can be done better.
It is the ignorant that Microsoft aims such messages at. Those who don't
know it can, really can, be better.
>
> Software development is a very difficult process (you really don't
> need me to tell you this). It is *impossible* to create error free code
> and it's equally impossible to test out each and every bug scenario.
But it's not impossible to create code that has fewer errors than exhibited
by some major software publishers, who too often are driven to push products
out the door before they are ready. To give a non-Microsoft example, the
Dreamweaver discussion group on the Macromedia news server has been full of
posts in recent weeks about problems with Dreamweaver MX 2004. It's not hard
to come to the conclusion that this product was pushed out the door to meet
some arbitrary deadline, rather than to make sure that the product is at
least minimally stable and bug-free.
Some of the most infamous Miscrsoft issues have been the ubiquitous "buffer
overflow." This problem crops up over and over and over, like Whack-A-Mole.
And this almost 2 years(!) after Bill Gates began his "trustworthy
Computing" initiative.
>
> As for documentation, we (as in the "collective we") are the ones
> that create that documentation. I hope that my documentation will
> stand up to the high standards and expectations that have been set,
> and I'm sure you have the same hopes. Obviously, some of us in
> the collective we are falling short of the mark. I hope it's not me - is
it
> you?
No one is perfect. But there's a double standard too: it's OK to deliver the
software with known bugs, but there can't be one typo or grammatical error
in the docs or else. (That's not to say I _accept_ such erros in the docs; I
know only that, especially in large doc sets that such things are the
product of real humans doing the work.)
>
> I guess I'm just trying to say "people who live in glass houses should
> not throw stones", or "clean up your own back yard", or something
> trite like that. We are imperfect people living in an imperfect world.
> As such, there are going to be hiccups, but really, we're all just
> doing the best we can. It's not like "we" are intentionally creating
> buggy software or inadequate documentation.
>
Actually, many companies do. They often *know* that significant bugs are in
the software they release, but they release it anyway. With a readme doc to
CTA. As if that makes it OK. The pressure comes from needing to get a
product out for a trade show. Or to generate income for this current
quarter's balance sheet. Or any number of other things that put profit
before quality, short-term cash over long-term success.
And speaking of inadequate documentation, how many times have any of us been
brought on board at the last minute and told to "throw something together"
to document this new app. I worked at a company once where my boss--who I
really liked and respected, and I went to that company in large aprt because
she was the manager there--was told that a new product was abot complete and
ready to go in 2 days, and could she write all the docs for it now.
2 days.
She did it. I never got to see it. I know the writing itself must have been
good, but was the documentation adequate? How could it be in 2 days? Not
long afterward, she left, and me not long after that.
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
