RE: Task-based vs. System-Based Procedures

[Bill Burns <BillDB -at- intl -dot- com>]

Hmmm. I guess when I see some really competent and experienced tech writers
addressed in such dogmatic, condescending tones in this forum, I get a
little miffed. And right now, I'm a little too grounded in reality to let it
slide.

Anthony Markatos writes:

> This is a very common misconception.  
> 
8< snip >8

> Such confuses systems design with bad systems design.
> 
8< snip >8

> Make no mistake about it, in good systems analysis/design, the developer's
> 
> perspective is EXACTLY the same as the end-user's perspective.  
> 
8< snip >8

> This is THE major principle upon which formal systems 
> analysis/design techniques - such as Structured Systems Analysis and
> Design 
> - are based upon.
> 
I've brought this up before on the issue of application development and
academic ideologies, and I certainly don't want to discourage people from
improving their processes, but isn't this scenario just a tad pollyannish? I
mean, it's one thing to debate whether the task-based and system-based
perspectives should be the same. It's another thing entirely to claim that
there's no distinction between how a user approaches an application and how
a developer designs it. I find it rather reductionist in terms of practice
(as opposed to the ideal world that academics keep fathoming) to claim that
the legitimate software development world follows this strict set of
principals and anything that falls outside of it is wrong/flawed/lacks
integrity/does mean things to animals and small children. 

The disparity exists between what applications do and what users want to do
with the applications. Like it or not, dem's da fax. Few of the applications
I use on a day-to-day basis reflect this Structured Systems Analysis
methodology, and few of the applications I've documented follow it.
Sometimes, the current state of technology simply prohibits it (that is, for
a product that's going to ship on time).

I'm just a little tired of this attitude that there is one and only one way
to do a job. If that's what you're looking for as a technical communicator,
then you are out of luck. No amount of dogmatic preaching about how the
academic world says it should be done is going to change how people do their
work. What's more, the longer the ideologues spend touting theories based on
nonexistent development conditions, the further detached they will be from
the real world of software development.

Got a burr up my backside today. 

Bill  Burns - Eccentric Technology Consultant <--documenting eccentric
technologies perhaps
billdb -at- intl -dot- com