Path: utzoo!attcan!uunet!wang!wdr
From: wdr@wang.com (William Ricker)
Newsgroups: comp.software-eng
Subject: Re: visual languages
Message-ID: <1990Mar2.143526.17023@wang.com>
Date: 2 Mar 90 14:35:26 GMT
References: <98229@linus.UUCP> <11202@encore.Encore.COM> <SDL.90Feb23164916@lyra.lyra.mitre.org> <1380@Terra.cc.brunel.ac.uk>
Organization: Wang Labs, Lowell MA, USA
Lines: 48

cs86eew@cc.brunel.ac.uk (Eoin Woods) writes:
>>In article <11202@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes:
>>
>>> About 8 years ago I was
>>> part of a startup which had a person who had been at Softech.  He tried
>>> to promote SADT, but wound up creating friction and blocking progress in
>>> many imaginative ways.  He left after 9 months without having written a
>>> single line of code, and a demo scheduled for the board of directors in
>>> two weeks.
>>> 
>>> Was it him, or us, or SADT?
>I could have been you, it probably was him but it can;t have been SADT - It
>can't produce friction - only the human's using it can!!

As an ex-SofTechie who was annoyed that SofTech never trained him in SADT,
but has worked elsewhere with ex-SofTechies even more arrogant than
myself, including one SADT co-developer, I suspect the friction was
produced (a) by the ex-SofTechie, a lot of us have awfully good opinions of
our own opinions, consulting houses breed that; and (b) aggressively
ramming his favorite methodology down peoples throat as *the one true way*.

If the original poster would like to mail me the name of the suspect 
*privately*, I might be able to reply more conclusively as to his reputation
and likely guilt or innocence.  If I don't know him, one of my even-more
arrogant ex-colleagues can tell me...

Note that a good designer *can* be an asset to a project even if s/he never
writes a line of code.  But a good analyst/designer by definition is a 
builder of consensus, not friction.  The JAD methodology from PRI is the 
"hot"  new replacement for SADT in this area.

>Besides, I think SADT is really quite good !
  
I rather like it myself.  I do note that both L.J.Peters and C.F.Martin
comment that it, like abstract DFD octupi-charts, are difficult to explain
to the sponsor-clients of large systems (executives, not programming 
managers); and that SADT reviews with less experienced or less trusting
reviewers drop into gnit-picking about "why is this flow/arc a control not
data?" when what should be discussed is three-boxes or four-boxes to 
decompose this node.

We have stolen the "kit" and "author-reader cycle" concepts from SADT,
whereby people provide 12-48hour turnaround on small pieces of spec,
with context and feedback, in a structured interaction, without benefit
of conference room.  And we use whatever diagram style fits, or just memos
(usually from an outliner) for the body of the "kit".

Bill Ricker