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.
Both NASA software developers and commercial software developers have
survival as their objective. The difference is that the NASA people are
totally devoted to the survival of their clients, while commercial software
developers are concerned about their own survival in the marketplace. For
NASA, any bug threatens the clients. Not so in the commercial marketplace,
where software bugs have become the price of "progress". Everything has its
price. For NASA, the price of a bug is the death of the client. For
commercial software, the dilemma is that the client won't pay the price
needed to assure bug-free software, so it is not surprising that the
commercial software development environment differs markedly from that which
prevails in the commercial marketplace. Both approaches could be justified
by the same risk management methodology, because the difference is in the
nature of the dominant risk factors.
================================================================
At 12:51 PM 4/26/00 -0500, Dave Whelan wrote:
>Whether you are developing a software program or a new car is irrelevant:
>shoddy work causes the same quality problems and overly cautious engineering
>causes the same marketing problems. The shuttle project is at one extreme,
>buggy software fraudulently released too soon is at the other. One is
>something to be proud of, the other makes a lot of money. Most of us are in
>the middle, we want to be proud of our work and we want to earn a living
>from it at the same time. A balance is needed but, as developers, we should
>always try to follow classical engineering development principles to balance
>the many powerful influences on the other side concerned only with profit.
====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory -at- primenet -dot- com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo -at- omsys -dot- com with "subscribe framers" (no quotes) in the body.
