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: Data Flow Diagrams From:"Anthony Markatos" <tonymar -at- hotmail -dot- com> To:chris -at- bdk -dot- net, tonymar -at- hotmail -dot- com Date:Thu, 13 Jan 2000 17:28:37 PST
Chris Kowalchuk said:
Let me first say that I too, as a tech writer who sometimes helps
develop software specs, typically resort to data flow diagrams. Whenever I
do, the programmers are amazed.....
Tony Markatos responds:
Wow! - there are at least two others on this planet who create DFDs (you and
Win). What a feeling! - I am not alone! :-)
Chris Kowalchuk said:
[Computer programmers do not create DFDs because] ........Computer
programming has a long history of being approached from a "just make it
[But (software) engineers do create DFDs because] ..... an engineer who
could not do a proper spec or map out a process would probably not make it
out of engineer school.
First let me emphasize that I am talking about REAL Data Flow Diagrams, not
"poor-man" imitations - often called things like Process Flow Diagrams,
Process Diagrams, Flow Diagrams, etc.
Now to comment on your comment: The older I get, the truer rings the old
saying "Believe none of what you hear and only half of what you see." And,
while your comment logically makes sense, it contradicts what I have seen.
I have, as a business analyst type, lead (larger-scale) requirements
specification projects which included "engineers" having Phds in IT from MIT
and Stanford (and a Harvard MBA type, but he don't count). These guys were
sharp, like real sharp - except when the need was to create Data Flow
Diagrams. Then, mysterious things would always happen, and I would,
inevitably, be the only one doing them. They were "hungry" for my output,
but I was the only DFDer.
At one(a large Southern California aerospace) company, I was a member of an
elite DFD "gruppie" department. (I was drafted into it - I don't "gruppie"
anything.) These people ate, slept, and breathed DFDs. They constantly
talked about the benefit of them. They developed a large in-house library
on them. They taught evening courses in them. One guy - a real
"borne-again Christian" type - would often loudly quote famous passages from
DeMarco and Yourdon (famous DFD authors). But, funny thing, when it came
time to actually do DFDs (like for work); I was, once again, alone.
So maybe you have worked with engineers who create DFDs. If so, then I have
only worked poorer-quality companies (Note: I have worked coast-to-coast,
large-medium-small, and for several international consulting companys.)
Don't get me wrong Chris, I am definetly pro-DFD (and other SSAD
techniques). Properly used they are, as it sounds like you have discovered,
I think that a major reason for there gross underutilization has been the
way they were taught. Example: Yourdon used to say that DFDs without an
accompanying data dictionary were merely "rough-sketches". This scares
people. For in the final analysis, Structured Systems Analysis is merely
rigorously enforced honesty. And the human capacity for honesty is limited
- increasing I think, but still limited.