Re: Data Flow Diagrams

[Chris Kowalchuk <chris -at- bdk -dot- net>]

Some comments (a rant?) sparked  by Anthony Markatos' reply...

OK, not wanting to take on airs, allow me to admit that I have only
dabbled in the world of DFDs. At one time I was charged with the task of
automating some processes, and not knowing thing one about any given
programming language, I figured the most useful thing for me to do would
be to study some DFD methods, define all the entities and their
relationships, map out the business processes (that's what the "business
analyists" are supposed to do, right?), and just keep going into more
detail on the entity relationship and process flow diagrams until we had
the whole process defined in detail, and then I hired some programmers
to convert my logic into workable code. I did that because I didn't know
any better. As a non-programmer, I figured I was laying out the best
possible spec. In general, the programmers were impressed. There was no
doubt about what I and my client wanted.

Now, I am pro-DFD too, but one of the potential problems with them seems
implicit in your discussion of them: they can take a long time.
Furthermore, the folks who like to do them can fall in love with them,
and their lovely DFD art-piece becomes more important (to them) than the
reasons behind why they needed to be done in the first place. That
objection, while valid enough under certain circumstances, can generally
be overcome with good project management. Design is good. Futzing is
bad. Management must determine the difference. In general, however,
money and time spent on the design end is, in my opinion, well spent. If
you have mapped everything out, then design flaws or problems become
apparent in the design phase, not in production, or worse,
post-production (or implementation in the case of business systems).
It's way cheaper to alter your DFD than it is to recall your defective
product or realize that the business system you have set up does not
actually do what you wanted, but in North America especially, design
time is often seen as a prohibitive cost rather than necessary for
high-quality production. On the one hand we want to manage the financial
end of things to death and on the other we don't care what kind of
products we produce or systems we implement as long as they are done
quickly and we beat our competition to the punch. The kind of "fake" DFD
Tony is talking about is exactly that sort of "marketing concept"
diagram that I think amuses executives but has nothing to do with the
design process. But businesses large and small are often geared to go
from marketing concept to sold product with as little design as
possible. Just look at the whole computer and software industry as a
prime example. Buying release 1 of any software product (with a few
exceptions) is like paying the company for the priviledge of
participating in its test market. No one seriously expects new software
to work very well, but should that really be the standard? I see a huge
competitive advantage for the first company to start releasing major
bug-free software on the first go-round. Can't be done? I wonder...

My $0.02

Chris Kowalchuk