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.
Bruce Byfield writes:
> One point that the article doesn't address is that free software and
> open source software is supposed to address this problem. The
> argument is that, if the code is freely available, then problems are
> discovered and corrected more quickly. This claim is widely believed
> and repeated, and it's probably the main reason why free and open
> source software is spreading.
You're getting it backwards, Bruce. The claim is not that this
*is* what happens (although by this point anecdotal evidence is
overwhelming that it does) but that this is what *can* happen, and by
definition cannot happen with closed-source software. C'mon, you
edit Maximum Linux, you should know this :-).
Programmers by nature are people who, if they see the TV picture
rolling around, and see the V-hold knob, need to reach out and twiddle
the knob to adjust the picture. They like tinkering with things.
They hate having to live with broken things that are obviously broken
and can be obviously fixed - if only they had the source.
Most programmers have had the experience of having to make a
broken closed-source product work - it can be excruciatingly annoying
just to figure out what the heck is going wrong, let alone come up
with a workaround to fix it. I've been stuck in that position and it
sucks, particularly because quite often the product in question is
wildly overpriced and haphazardly implemented (and seldom designed).
To add insult to injury, you know you're being forced to go
through hell to make something work when your employers paid tens of
thousands to hundreds of thousands of dollars for it! Usually against
your advice or without consulting you!
> At the very least, the article should have mentioned it. However, I
> would be even more interested in seeing an an analysis or challenge
> of the claim. So far as I know, it's never actually been tested. The
> logic seems reasonable enough, but I wonder if the practice would
> be, too.
It'd be interesting to see an analysis of the claim, but I doubt
you'll ever see a real analysis, because it'd need to analyze
commercial closed-source software as well, and suddenly you're in the
realm of restrictive licenses that prohibit you publishing *anything*
about the software once you buy it. For example, in the application
server market it's common for commercial application servers to come
with a license prohibiting publishing performance benchmarks.
> No 'Silver Bullet' for Software's Growing Complexity
The "silver bullet" bit is a reference to the classic "No Silver
Bullet" essay by Fred Brooks (author of _The Mythical Man-Month_; the
silver bullet essay was a followup many years later, saying that the
various technologies developed since then are not silver bullets).
> "This is just a national scandal, this problem with software complexity and
> unreliability," says Leon Kappelman, director of the Information Systems
> Research Center at the University of North Texas in Denton. "No one should
> have to put up with computers being so unreliable or so difficult. We don't
> put up with this with any other product we use."
I don't know whether to laugh or cry when I see this sort of
comment. Typically people who say things like this are being dramatic
and have no grasp of what they're actually talking about. I'm
reminded of people talking about how easy and intuitive an interface a
car has - forgetting that most people need many hours of personalized,
one-on-one instruction and supervised practice before they get a
license, and are still far from competent at doing a handful of simple
things (accelerate, brake, turn left, turn right, reverse, etc) until
years later.
> Across the country these days, community and national leaders are talking
> about such issues as the "digital divide," the severe shortage in
> technically skilled workers, massive investments in education to increase
> the skills of young people and those willing to be retrained and how high
> salaries in tech fields are transforming neighborhoods.
Also typical inflammatory prose; all of these issues are hot
topics but are by no means clear-cut. There've been cogent and
convincing cases presented that in fact we have no shortage of tech
workers (just a shortage of business willing to retain and retrain
older workers), and that the so-called high salaries in tech fields
are in fact quite moderate for the most part (one article I saw cited
a report that plumbers' income levels rose about three times as much
as programmers' income levels).
> But few people are talking about how to make technology easier to use.
> There's a universal assumption that people will have to adjust to the
> rampant, irrational and escalating complexity of a hyper-technologized
> society--or fall into the ranks of the losers and the ignorant. This split
> is likely to characterize modern life in the 21st century.
I do think that we're likely to see the concept of "programmer"
and/or the general distinction between a somebody who's familiar with
and comfortable using and manipulating information technology
disappear. Only one in five working programmer has a degree in
computer science. Most people being paid to work with information
technology are actually competent domain experts who are also
competent to use high-level information technology in tasks relevant
to their domain.
I do think that there is insufficient emphasis on understanding
what the question is, before we figure out the answer (this is the
heart of usability, in my opinion). However, I also think most folks
are taking for granted the gains that have been made in the last ten
years in this area.
Steven J. Owens
puff -at- guild -dot- net
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
