Re: So this is why...!
For my colleagues who work in the software industry, there's a report on==================================================
www.slashdot.org quoting the consulting group Software Productivity Research
that the average programmer spends only 47 hours per year adding value to a
product. The rest of the time is spent debugging, testing, or working on
projects that are tanked before release.
Considering that our industry is heavily dependent in turn on the software
industry, this is alarming news indeed. But it does explain a lot.
Below is an extract from an article that appeared recently in the LA times:
http://www.latimes.com/business/cutting/20001127/t000113753.html
The extract cites the same source as slashdot.org, and explains
what they (software engineers) do the rest of the year.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Capers Jones, chief scientist for the consulting firm Software Productivity Research in Burlington, Mass., has estimated that "about 60% of the U.S. software work force are engaged in fixing errors which might have been avoided." Moreover, he writes, for software engineers, "only about 47 working days in a full calendar year are available for actually developing or enhancing software applications." The rest of their time, about 150 days, is spent on testing, fixing bugs and working on projects that are later canceled.
Jones concludes in his published paper, "There would probably be no software labor shortage if software quality could be brought under full control."
Jones writes, "Much of the work of software engineering is basically 'wasted' because it concerns either working on projects that will not be completed, or working on repairing defects that should not be present at all."
Jones' figures do not even address the vast overhead of tech support and maintenance required within organizations that use even modestly sophisticated computer software and networks.
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Of course, Andrew Plato would argue that this problem, like the problem
with writers, is that the software engineers aren't using their brains enough.
But everyone who has seriously addressed the problem of poor
software quality would agree that improved processes are the answer,
not more jolt-cola-swgging cowboy programmers who claim they could
fix all the bugs if everyone would just leave them alone, and stop
making them follow procedures.
Does that sound familiar? Andrew argues that if you eliminate
processes, don't impose structure, forget about content
management, forget about configuration control, and make writers
use MS Word, the result will be better documentation at a lower
cost. I contend that Andrew's approach produces the writing equivalent
of spaghetti code, which results in the same downstream catastrophe
(huge overhead, increased tech support costs) produced
by his cowboy equivalents in the software engineering profession.
====================
| 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by SOLUTIONS, Conferences and Seminars for Communicators Publications Management Clinic, TECH*COMM 2001 Conference, and more http://www.SolutionsEvents.com or 800-448-4230
---
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.
Previous by Author:
Re: Is Word Formatting in End-User docs important? [was:Word Help (pr oblem solved)]
Next by Author:
Re: So this is why...!
Previous by Thread:
So this is why...!
Next by Thread:
Re: So this is why...!
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads