Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!mtune!codas!usfvax2!jc3b21!fgd3
From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Newsgroups: comp.sys.amiga
Subject: Re: Structured Techniques From Hell (was: Electronic Arts bashing)
Message-ID: <135@jc3b21.UUCP>
Date: Wed, 22-Jul-87 15:15:35 EDT
Article-I.D.: jc3b21.135
Posted: Wed Jul 22 15:15:35 1987
Date-Received: Sat, 25-Jul-87 03:15:21 EDT
References: <1660@cadovax.UUCP>
Organization: St. Petersburg Jr. College, FL
Lines: 203
Summary: Bad management is the problem, not structured design techniques.


In article <1660@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes:
|In article <893@hp-sdd.HP.COM> nick@hp-sdd.UUCP (Nick Flor) writes:
|||All the structured design and analysis will not save an idiot.
||
||It *is* set up to save the idiot.
|
|Actually, this is one of the main problems I have with structured
|design doctrines/dogmas.  It treats your good programmers like they
|don't know what they are doing.  Virtually any good programmer has
|come to the same conclusions about the design process that structured
|design techniques have.

     No.  By your own statement the good programmers recognize the benefits
of structured design techniques.  What structured design attempts to do is
make those programmers who don't quite know what they are doing behave as if
they did.  In other words, it provides the inexperienced a technique which
will make them more effective.

||Do you even know anything about
||the structured design/analysis process?  Part of the process involves
||going over your design THOROUGHLY with your project team.
|
||You should
||be able to catch all the bugs the user could potentially discover through
||normal use.  Too many packages out there contain bugs that are discovered
||to pathological interference by buffoons.  Structured design eliminates
||most of this.
|
||In large projects, the documentation that results from following
||the methodology not only facilitates the delegation of well defined
||tasks to different people but also makes it easier for future project
||teams to understand/fix/enhance/modify etc. the code reliably.
|
|Sure, but if you need Yourdon or Marcus to tell you that, or worse, to
|setup rigid dogmas to accomplish such, you're already beyond hope.

     An individual working entirely alone can use any techniques which suite
him.  Someone who works with other people has to communicate with them in a
way that is mutually understandable.  The adoption of a structured design
methodology brings order to the design process.  Designers, programmers, and
analysts have a technique which brings errors to light sooner.  The sooner
errors are recognized the earlier (and more cheaply) they can be corrected.
You don't achieve those benefits if just one member of the design group uses
structured techniques.  The structured approach facilitates communication by
reducing the time it takes for one person to understand what another is
doing.

|Management imposition of structured techniques has attacked the *symptom*
|of the problem, not the problem itself.  And what is the problem?
|You've lost the ability to keep your programmers inspired and motivated
|and to be conciensious toward their job.  If you hadn't they would have
|been coming to YOU to tell you they've arrived at new ways of improving
|maintainability and bug-free-ness.

     Question: What is a manager?  Answer: Someone who believes in magic.
Most managers think they can buy a program or product, install it, and watch
their problems magically disappear.  So they declare structured design to be
the order of the day.  Then they go sit on their hands and look surprised
when the problems are still there.  You're right, Keith, that management
imposition of structured techniques doesn't solve the problem.  You can't
just impose structured techniques.  You have to teach people how to use
them.  If that's done properly programmers will be inspired and motivated.
They'll be excited by the way structured design techniques help them write
reliable code.  They'll see it as a better tool that lets them spend more
time on new development and less time on maintenance.

||Look folks, I'm just sick to death of some of the sh*tty code that gets
||published.  I'm not trying to flame anyone in particular, just immature
||attitudes towards software design.
|
|So what about the sh*tty code that gets published that was produced with
|structured design techniques?  And what good is the most maintainable
|code in the world, if the end product isn't worth using?  Or if the
|programmers primary goal has been to produce the best looking design
|documentation in the world?  The user never sees the design
|documentation, and you can't boot the design documentation in his
|disk drive.

     All other things being equal, an easily maintainable program is better
than one that isn't.  Of course you can use structured design techniques to
write bad programs.  You can write programs that are inefficient, hard to
use, or simply useless.  But if you have a good idea for a program and you
know how to use the resources of the target machine and you understand the
end users' needs structured design will let you design the same program
faster than a non-structured design.  Or it will let you build a better
(more reliable, more maintainable) program in the same time.  And it might
even suggest additional features that could be added because they could use
modules that were already required for the original design.  It isn't a
question of good programming versus structured design, it's a combination of
good programming AND structured design that's needed.

||When we finally get off of our high chairs and acknowledge that bottom-up-do-
||what-comes-easy-first design just doesn't work for software of considerable
||size, everyone will be a lot better off.
|
|What I object to, is not the theory of structured design per se, but
|the fact that many times, management is shoving it down peoples throat in
|an attempt to cover their own ass, because they're completely in the
|dark as to how to get a good product out on schedule without somebodys
|book telling them what to do.  I'd say they need some techniques to
|learn how to manage themselves out of paper bags.  And in particular,
|how to motivate people.

     The most motivated people in the world can't produce a product if they
don't know how.  If they're good, they can figure out how, but why should
everyone re-invent structured design?  A great deal of work has already been
done in the field of software engineering.  Let's take advantage of it, even
if it's "not invented here".

|I mean, if structured techniques didn't exist, it would be necessary
|to invent them.  Because there is an enormous market for a wonderful
|warm fuzzy band-aid solution to the 'software problem'.  Never mind how well
|it might really work, or if there are other methods that can be used.
|Never mind asking the programmers what they think might be good ways
|to address the problems, or what shoving ANY technique down peoples
|throat is going to do their motivation and job satisfaction.  Some guy
|over there has written books on the subject that everybodies buying,
|so he must know what he's talking about (and never mind that he turns
|around and tries to sell you the software tool to do you the job for
|you for big bucks either).

     You're absolutely right, Keith.  No technique is going to work with
people who aren't motivated.  And nothing turns off motivated people than a
manager whose attitude tells them "You guys are so dumb I need this system
to keep you in line."  But the problem is with the manager's approach, not
the structured design system.  Another manager, pushing the same techniques,
whose approach was "Here's a tool that you'll find really helpful" will have
lots better luck.

|Any project that is so complicated that you need to implement dogmas
|of structured techinques to handle, is probably ALREADY too high-level,
|and has not been broken down enough.  It's up to the product managers
|and other managment to learn a little top down design themselves, and
|not foist a ridiculous set of constraints on the design of a product
|which begins to look like the final answer to the worlds problems in one
|single module.

     To me, this sounds like any project big enough to require structured
design techniques should have had structured design techniques applied
earlier.

|Structured dogmas blame the programmer for everything.  You don't know
|how to design your code, noone can support your code, you don't know
|how to document your code, you don't know how to test your code.  And
|it could never be that QC or Test or Documentation departments are the
|ones that don't know how to do their job, it's up to you to spoon feed
|them with the most outstanding wonderful design documentation in the
|world.  That makes their job easy.

     It's your code.  If you can't document it no one can.  If you can't
tell people how to use it QC and Test people can't put it through its paces.
The Documentation department's job is to tell the end user how to operate
your software.  They can't do that if you don't tell them how it works.

|                                    But it does it by making yours (as a
|programmer) more difficult.  As if things weren't complicated enough as
|they were, learning 80386 machine language, understanding UNIX and DOS,
|keeping up with technology.  And never mind that many programmers aren't
|cut out to be good writers, or good illustrators.  That some of them
|may have learned programming because they didn't cut it in english classes.
|That they may be poor communicators.  We can force them to be good
|jack-of-all-trades and do everybodies work for them.  After all, they're
|getting paid more than people in those other departments.

     Of course, if you just want to be a coder, with no influence on the
design, someone else can do all these things and give you detailed
specifications.  But if you want to be creative, if you want to use your
ability to write code to make the computer do what you want it to do you
must take the responsibility that goes with that level of work.  You must be
prepared to make your products interface with others'.  You must be ready to
explain how to use your software and how to maintain it.  Whoever plays the
creative role has to explain the implications of his creation--no one else
can.

|There are two basic ways you can run a department.  You can take the
|people you have, and figure out how to build the best organization you
|can around what their abilities are, or you can design the perfect
|organization, and try to fit the people you have into the various 'slots'.
|I agree, its much easier for a manager to do the latter.  Otherwise, you
|have to have an organization that is adaptable, as people come and go, and
|you will have to do some adapting when that happens.  However, having
|an adaptable organization may have other benefits when other things
|change too, like technology, the marketplace, etc.  I prefer an
|organization that tries to make the best use of peoples talents, not
|one that tries to fit everyone into the 'mold' of a perfect programmer.
|Unfortunately, until enough management learns of the importance of motivating
|people, and ways of doing such, the market for *magic* techniques will
|just get larger and larger.

     How true that is!  But once again, those are complaints about poor
management that really aren't relevant to the question of structured design
techniques.  Think how much worse things would be if these same poor
managers actively prevented the use of structured design techniques and
worked to block the adoption of programming standards.  Unbelievable?  I
wish it were.

--Fabbian Dufoe
  350 Ling-A-Mor Terrace South
  St. Petersburg, Florida  33705
  813-823-2350

UUCP: ...seismo!akgua!usfvax2!jc3b21!fgd3